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(57) Abstract 



A virtual memory system and method enable a computer system to use a virtual memory address space larger than the size of physical 
primary memory while swapping few, if any, pages out to secondary memory. Primary memory is divided into a work space, used for 
storing uncompressed pages in current use, and a "Compression Heap". A MappedOut storage space, which includes the Compression Heap 
and a portion of secondary memory, is used to store all pages swapped out of the work space. A virtual memory manager dynamically 
determines the number of pages of primary memory which need to be included in the woric space, and moves pages of primary memory 
into the work space from the Compression Heap as needed. Pages are selected to be swapped out of the work space to the MappedOut 
storage space on the basis of memory usage data. A data compressor compresses at least some virtual memory pages prior to their storage 
in the MappedOut storage space, and a data decompressor decompresses the compressed virtual memory pages when a fault occurs on those 
pages. The virtual memory manager includes logic for preferentially compressing and storing swapped out viitual memory pages in the 
Compression He^ so long as the MappedOut storage page includes a sufficient number of pages of primaxy memory to store those virtual 
memory pages, and for storing ones of the swiped out virtual memory pages in secondary memory when insufficient space is available in 
the Compression Heap. 
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VIRTUAL MEMORY MANAGEMENT SYSTEM 
AND METHOD USING DATA COMPRESSION 

A portion of the disclosure of this patent document contains materials to which 
a claim of copyright protection is made. The copyright owner has no objection 
to the facsimile reproduction by anyone of the patent document or the patent 
disclosure, but reserves all other rights whatsoever. 

5 

The present invention relates generally to virtual memory management systems 
and hfiethods, and particulariy to a system and method for improving the 
perfomiance of a virtual memory management system by utilizing part of a 
computer system's high speed random access memory (RAM) to store "swapped 
10 out" pages in compressed form. 



BACKGROUND OF THE INVENTION 



15 



20 



In most computers having virtual memory management, the available address 
space for the computer's operating system and application processes exceeds 
the amount of physical RAM available. As shown in Figure 1. a computer system 
100 will typically have a central processing unit (CPU) 102. such as a Motorola 
68040 or Intel 80486, a primary memory 104 (typically random access merriory 
(RAM)), a secondary memory 1 06 (typically one more magnetic or optical disks), 
and a cache memory 108 for storing a copy of the memory locations most 
recently addressed by the CPU 102. The cache memory 108. or a portion of 
the cache memory, is often fabricated as part of the same integrated circuit as 
the CPU 102. 
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As indicated in Figure 1 , the CPU 102 is typically the fastest of the components 
In the computer system, followed by the cache memory 1 08, the primary memory 
104 and finally the secondary memory 106. Also shown In Figure 1 is a virtual 
memory unit (VMU) 110, which is often fabricated as part of the same Integrated 
circuit as the CPU 102. 



Conventional Virtual Memory Management 

The following is a brief explanation, for those readers not skilled In the art, of 
how conventional virtual memory management works. The virtual memory unit 
110 enables programs executed by the CPU 102 to utilize an address space 
that is larger than the actual storage capacity of the primary memory 104. For 
Instance, a computer with 8 MBytes (MegaBytes) of RAM might utilize a virtual 
address space of 1 6 MBytes, or even more. The VMU 110 uses a "page table" 
(discussed in more detail below) to store one "page table entry" for each virtual 
memory page In the computer's virtual memory address space. One version 
of a page table is shown in Figure 4 (although that page table contains features 
particular to the present invention). 

Each page table entry includes an address value and status flags indicating 
whether the corresponding virtual memory page is stored in primary or secondary 
memory. Thus, the status flags in a page table entry indicate whether the 
address value in that entry corresponds to a primary memory location or a 
secondary memory location. For a computer system using pages that are 
4 KBytes (KiloBytes) in size, a 16 MBytes virtual address space would occupy 
4096 pages, and thus the page table would contain 4096 page table entries. 

Since the CPU uses virtual addresses for its internal address computations, the 
virtual memory unit 1 10 translates each CPU specified virtual memory address 
values Into a primary memory address value when the status flags in the 
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corresponding page table entry indicates that the CPU specified address is 
currently stored In the primary memory 104. The translated address signal 
generated by the virtual memory unit 110 is then used to address the primary 
memory 104* When the CPU specified virtual memory address value is not 
5 currently stored in the primary memory 104, the page table entry accessed by 
the virtual memory unit will have a status flag indicating that fact, which causes 
the virtual memory unit to generate a 'fault signal". The fault signal indicates 
the virtual page in which the fault occurred and also indicates, either directly or 
indirectly, the values stored in the address and flag fields of the corresponding 
10 page table entry. 

Whenever a virtual memory fault occurs, a software procedure, typically called 
a virtual rhemory manager, locates a page of primary memory that can be 
mapped Into the virtual memory page In which the fault occurs. If the virtual page 

1 5 upon which the fault occurred was previously swapped out to secondary memory, 
the contents of the virtual memory page are copied into the page of primary 
memory. The virtual memory manager then updates the page table entry for 
the virtual page to indicate the physical primary memory page in which the virtual 
memory page is now located, and then signals the virtual memory unit 1 10 to 

20 resume operation. Upon resuming operation, the virtual memory unit 110 again 
accesses the page table entry for the CPU specified virtual memory address, 
and this time successfully translates the virtual memory address into a primary 
memory address. 

25 While there are many other aspects of virtual memoiy management not discussed 
here, the salient point here is that in standard virtual memory management 
subsystems, at any one point in time a virtual memory page is either in primary 
memory or secondary memory, or possibly In transition from one to the other. 

* 

30 
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Basis for Present invention 

During the period from 1 983 through 1 993, CPU operating speeds have Increased 
much more dramatically than disk memory and other secondary memory 
5 operating speeds. As a result, the 'penalty' (on a computer system's operating 
speed) associated with the use of virtual memory has actually t>een getting worse, 
in that using a fast CPU causes more CPU cycles to be wasted when waiting 
for a page of virtual rnemory to be swapped in from secondary memory to primary 
memory. 

10 

Consider for a moment the relative speeds of (A) swapping a page out to disk 
(i.e., the prior art) and (B) compressing a page of 4096 bytes and storing it in 
a RAM heap for compressed pages (i.e., the present Invention). Each disk 
access, almost regardless of the page size, takes an average of 9 to 20 

1 5 milliseconds, depending on the disk's operating speed. We will assume the use 
of a moderately fast disk with a 10 millisecond access time. Tests of the data 
compression and decompression procedures used in the preferred embodiment 
Indicate that a page of 2048 16-bit (2-byte) words (i.e., 4 KBytes) is compressed, 
on average, in 8 milliseconds, and is decompressed, on average, in about 2.3 

20 milliseconds using a 25 MHz Motorola 68040. When using a 50 MHz Motorola 
68030, the average compression and decompression execution times for a page 
are 12 milliseconds and 3.5 milliseconds, respectively. 

As indicated above, data decompression is much faster than data compression. 
25 Thus, decompressing a compressed page takes much less time than recovering 
a swapped out page from disk (typically less than 25% as much time). 

Another basis for the present invention is the observation that the contents of 
primary memory (i.e., RAM) in most computer systems is much more 
30 compressible than the average disk file. In particular, the inventors of the present 
invention have observed that the contents of the swappable pages in RAM are 
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typically compressible by a factor of three using standard Lempet-Zif data 
compression techniques and garbage collection of deallocated memory address 
ranges, while the contents of disk files are typically compressible by only a factor 
of 2 to 2.2 using standard Lempel-Zif data compression techniques. Given an 
5 average compression ratio of 3:1 . consider the following: if half (e.g., 4 MBytes) 
of a computer's 8-MByte RAM is used for normal memory access, and the second 
half of RAM (4 MBytes) is used to store compressed pages, then the total data 
content of RAM will be (4 MBytes 12 MBytes s 16 MBytes), on average, twice 
the RAM's normal storage capacity. 

10 

Thus, using the present invention. It is possible to have a virtual memory address 
space that is twice the size of the computer's primary memory without having 
to swap any pages out to disk. 

15 .Of course, the contents of RAM are not always of average compressibility, and 
thus it may be necessary at times to swap some pages out to disk. However, 
as noted above, decompressing a page generally takes less than 25% as much 
time as a disk access, and thus even if a compressed page is swapped out to 
disk, the use of data compression slows the recovery of that particular page by 

20 only about 25%. Furthermore, in normal usage less than 20% of pages removed 
from the "work space" will be swapped out to disk, and thus, on average, the 
time for recovering from page faults is substantially reduced. (Actually, in most 
cases, no pages will be swapped out to disk, with 20% representing the normal 
upper limit.) As shown by the following computation: 

25 

0.80 (percentage of pages) x 0.25 (relative speed of access) 
+ 0.20 X 1.25 = 0.20 + 0.25 = 0.45 

the average page fault response time is reduced by about 50% using the present 
30 invention with a CPU of only very average capability, while using less disk space 
than standard virtual memory subsystems. When using a CPU at least as 
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powerful as a 40 MHz 68040 or a 66 MHz 80486DX-2 microprocessor, the 
average page fault response time Is reduced by 60% or more, with 
correspondingly better perfomnance for even faster processors. 

5 Another motivation for the present invention is that hard disk use is very power 
consuming for portable computers. Nomnally. using virtual memory on a portable 
computer would mean that the hard disk would be in almost constant use, thereby 
draining the computer's battery. Use of the present invention allows the use of 
virtual memory while eliminating or substantially reducing the power usage 
10 associated vdth swapping pages to and from hard disk. 

The present invention is generally applicable to any computer system having 
a virtual memory unit and a CPU at least as powerful as a Motorola 68030 or 
an Intel 80386 mnning at 25 Megahertz. In such computer systems, use of the 
15 present invention will reduce the latencies associated with the use of virtual 
memory and thus will improve overall system perfonrnance. In addition, the 
present invention will enable many computer users to avoid the purchase of 
additional random access memory since the "penalty" associated with using virtual 
memory instead of physical random access memory will be reduced. 

20 

SUMMARY OF THE INVENTION 

In summary, the present invention is a virtual memory system and method for 
25 enabling a computer system to use a virtual memory address space that is larger 
than the size of physical primary memory while swapping few, if any, pages out 
to secondary memory. The computer's primary memory is divided Into a work 
space, used for storing uncompressed pages that are in current use by the 
computer system's operating system and applications, and a "Compression 
30 Heap'. A MappedOut storage space, which includes the Compression Heap 
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and a portion of the computer's secondary memory, is used to store all pages 
swapped out of the work space. 

A virtual memory manager dynamically determines the number of pages of 
primary memory which need to be included in the work space, and moves pages 
of primary memory into the work space from the compression heap as needed. 
Virtual pages are selected to be swapped out of the wortc space to MappedOut 
storage on the basis of memory usage data. The virtual memory manager 
includes logic for preferentially compressing and storing swapped out virtual 
memory pages in the Compression Heap (in primary memory) so long as the 
MappedOut storage space includes a sufficient number of pages of primary 
memory to store those virtual memory pages, and for storing ones of the swapped 
out virtual memory pages in secondary memory when insufficient space is 
available in the Compression Heap. Thus, the size of the work space is variable 
and the proportion of swapped pages stored In primary memory and in secondary 
memory are also variable. 

A page table stores a page table entry corresponding to each virtual memory 
page. Each page table entry specifies a tag value, conresponding to a location 
In the primary or secondary memory, and a plurality of status flags for indicating 
the status of the corresponding virtual memory page. The status flags includes 
a Mappedin flag having a True/False value that indicates when the tag value 
corresponds to a RAM page (in the active woric space) in which the corresponding 
virtual memory page is stored. 

A virtual memory unit (VMU) translates CPU specified virtual memory address 
values into primary physical address values when the Mappedin flag in the page 
table entries conresponding to the CPU specified virtual memory address values 
are True. The VMU generates fault signals when the Mappedin flag in the page 
table entries corresponding to the CPU specified virtual memory address values 
are False. 
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The virtual memory manager responds to each fault signal from the VMU by 
updating the page tablp entry corresponding to the CPU specified virtual memory 
address, value which caused the fault signal, so that the page table entry specifies 
a primary memory page and a Mappedin flag having a True value. The virtual 
memory manager includes a work space manager that defines a work space 
and a MappedOut storage space for storing virtual memory pages. The work 
space is located in a first portion of the primary memory. The MappedOut storage 
space is located in a second portion of the primary memory pages and in a 
portion of the secondary memory. 

A memory usage monitor stores memory usage data. The virtual memory 
manager includes swap out selection logic that selects, on the basis of the 
memory usage data, virtual memory pages to be swapped out from the work 
space to the MappedOut storage space. A MappedOut storage manager receives 
from the virtual memory manager the virtual memory pages selected to be 
swapped out. stores the received virtual memory pages In the MappedOut storage 
space, and adds the primary memory pages in which the received virtual memory 
pages were stored to the MappedOut storage space. 

The MappedOut storage manager includes a data compressor that compreisses 
at least some of the received virtual memory pages prior to their storage in the 
MappedOut storage space, and a data decompressor that decompresses the 
compressed virtual memory pages when the virtual memory manager responds 
to fault signals caused by VMU faults on the compressed virtual memory pages. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Additional objects and features of the invention will be more readily apparent 
from the following detailed description and appended claims when taken in 
conjunction with the drawings, in which: 



wo 95/18997 



PCT/DS94/14987 



-9- 

Figure 1 is a block diagram of the memory hierarchy in a conventional computer 
system. 

Figure 2 is a block diagram showing the memory hierarchy in a computer system 
5 using the present invention. 

Figure 3 schematically represents a typical virtusd memory address map for a 
computer system using the present Invention. 

10 Figure 4 is a block diagram of a page table (also herein called a page map) for 
a computer system using the present Invention. 

Figure 5 is a diagrammatic representation of one page table entry in the page 
table of Figure 4. 

Figure 6 is a diagrammatic representation of the virtual memory manager used 
in a preferred embodiment of the present invention. 

Figure 7 is a diagrammatic representation of a memory usage table that stores 
20 data Indicating which virtual memory pages in a defined virtual memory address 
space were least recently used. 

Figure 8 is a diagrammatic representation of a table used in a preferred 
embodiment of the present invention to store data representing a list of "best" 
25 pages to swap out from the computer's work space if it becomes necessary to 
swap pages out of the work space. 

Figure 9 is a diagrammatic representation of the Compression Manager used 
in a preferred embodiment of the present invention. 

30 
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Figure 10 is a diagrammatic representation of a "Sector Table* used in a preferred 
embodiment of the present invention to store data indicating which sectors of 
a seconjdary memory devices have been used to store swapped out virtual 
memory pages. 

5 

Figure 1 1 is a diagrammatic representation of a 'Main Map" table used in a 
preferred embodiment of the present invention to store data representing all virtual 
memory pages that have been swapped out of the computer's work space. 

10 Figure 12 is a diagrammatic representation of a 'Map Chain' table used in a 
preferred embodiment of the present invention to store data iridicating the order 
in which certain virtual memory pages were swapped out of the computer's work 
space. 

15 Figure 13 is a diagrammatic representation of the "Compression Heap" used 
in a preferred embodiment of the present invention to store virtual memory pages 
swapped out of the computer's work space. 

Figure 14 is a diagrammatic representation of the "Last Use" table used in a 
20 preferred embodiment of the present invention during the process of performing 
a data compression procedure on a virtual memory page. 

Figure 15 Is a diagrammatic representation of the "index Table" table used in 
a preferred embodiment of the present invention during the process of performing 
25 a data compression procedure on a virtual memory page. 

Figure 1 6 is a flow chart representation of the data compression procedure used 
in a preferred embodiment of the present invention. 

30 
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DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Tables 1-16 at the end of the specification contain pseudocode representations 
of software procedures relevant to the present invention. The pseudocode used 
5 In these appendices is, essentially, a computer language using universal computer 
language conventions. While the pseudocode employed here has been invented 
solely for the purposes of this description, it is designed to be easily 
understandable by any computer programmer skilled in the art. The computer 
programs in the pretended embodiment are written in the assembly language used 
10 for Motorola 680x0 microprocessors. 

Referring to Figure 2, a computer system 120 in accordance with the present 
invention includes a central processing unit (CPU) 102, such as a Motorola 68040 
or Intel 80486, a primary memory 104 (typically random access memory (RAM)), 
15 a secondary memory 106 (typically one more magnetic or optical disks), and 
a cache memory 108 for storing a copy of the memory locations most recently 
addressed by the CPU 102. 

Solely for the purposes of describing a preferred embodiment, it will be assumed 
20 that the CPU is a Motorola 68040 running at 33 Megahertz, that the primary 
memory 104 contains 8 MBytes of RAM, and that the secondary memory 106 
is a fast hard disk having a capacity of over 100 MBytes. Furthermore, it will 
be assumed that the computer system 120 used in the preferred embodiment 
is a Macintosh computer, produced by Apple Computer Corporation, running 
25 the Macintosh 7.1 operating system, it should be understood that this system 
configuration is not pari of the present vivention, but rather is simply one example 
of a context in which the present invention can be used. 

As shown in Figure 2, the primary memory 104 is divided into two portions: a 
30 Work Space 122 and a Compression Heap 124. A MappedOut storage space 
1 30, which includes the Compression l-leap 124 and a portion 1 32 of secondary 
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memory, is used to store all pages swapped out of the work space. The portions 
of primary memory allocated to the Work Space 122 and Compression Heap 
are variable, as will be explained below, and thus these portions of primary 
memory may not have fixed sizes. 

In a preferred embodiment using a virtual address space that is precisely twice 
the size of the physical primary memory, the portion 132 of secondary memory 
106 that is included in the MappedOut storage space is equal in size to the 
physical primary memory. Thus, in the preferred embodiment, for a computer 
system with 8 MBytes of RAM, the virtual memory address space will be 16 
MBytes and the portion 132 of secondary memory included in the MappedOut 
storage space will be 8 MBytes. 

Virtual Memory Address Map and VM Page Table 

Figure 3 shows a map 140 of the virtual address space in a computer using the 
present invention. The lowest addresses (i.e., near address zero) in the virtual 
address space are typically occupied by items that must always be present in 
primary memory: 

• the operating system's kemel 142, 

• interrupt vector tables 144, 

• the Page Table 1 46 (herein also called the Page Map) used by the virtual 
memory unit 1 1 0 to map virtual memory addresses into physical memory 
addresses. 

a disk driver 1 48, needed for sending pages of virtual memory to and from 
disk, and 

• a virtual memory manager 1 50, for responding to virtual memory unit fault 
signals. 

To that 'standard* set of unswappable Items, the present invention adds a virtual 
memory Compression Manager 1 52, which can be though of as part of the virtual 
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memory manager In the preferred embodiment, however, the VM Compression 
Manager 152 is a layer of software that is called by the VM Manager 150. 

As shown in Figure 3, a first portion of the virtual memory address space extends 
5 to an address that is twice as large as the physical RAM. Note that the variable 
"PhyMem" is equal to the size of the physical RAM, in units of bytes and that 
"2 X PhyMem" therefore means a value equal to twice the size of the physical 
RAM. This first portion of the virtual memory address space is used in the same 
way that conventional virtual memory is used: to store programs and data that 
10 can be directly addressed by programs executed by the CPU. 

The Work Space 122 comprises the unswappable items discussed above, plus 
all other pages of the "regular* virtual memory address space which are 
uncompressed and resident in primary memory. 

15 

A second portion of the virtual memory address space, located between virtual 
memory addresss '40 000 000 H - 2 x PhyMem' and 40 000 000 H (1 Gigabyte), 
is used by the VM Compression Manager 152 to store (A) a set of Compression 
Manager Tables 1 60 that are used to keep track of virtual memory pages stored 
20 in the MappedOut storage space 1 30, and (B) the Compression Heap 1 24. Thus, 
the Compression Heap 124 is assigned to a portion of the virtual address space 
that is not directly addressable by ordinary programs executed by the CPU. 

One page of virtual address space, just below the Compression Manager Tables 
25 160 (but which could be located in any other page of unusued virtual memory 
address space), is herein called the Transient Page 158. Whenever a physical 
RAM page is about to be mapped into a specified virtual memory address, in 
response to a page fault, the page is first mapped into the address of the 
Transient Page. That address is herein iat>eled the TransientPageAdr. The page 
30 is then usually filled with zeros, or with the previous contents of the virtual page. 
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and then the page is mapped into the specified virtual memory address for 
satisfying the page fault. 

The anriount of virtual memory address space assigned to the Compression 
5 Manager Tables 160 depends on the maximum number of virtual memory pages 
that can be In used, excluding virtual memory pages used by the Compression 
Manager Tables 160 and the Compression Heap 124. in the preferred 
embodiment it is assumed that the virtual memory address space useable by 
operating system and application programs (i.e., all programs excluding the VM 
10 Manager and VM Compression Manager) will not exceed twice the physical 
primary memory. 

As will be described in more detail below, the Compression Manager Tables 160 
include a Sector Table 162, Dictionary Tables 164 (including a l-astUse table 

15 166 and Index Table 168) having a fixed size of 136 KBytes, a Compression 
Buffer 1 70 of 6 KBytes, a Main Map table 172 and a Map Chain table 1 74. For 
a computer having 8 MBytes of physical RAM and 4-KByte pages, the available 
virtual address space is 4K pages, the Sector Table occupies 16 KBytes, the 
Main Map table 172 occupies 24 KBytes and the Map Chain table 174 occupies 

20 .16 KBytes, and thus the Compression Manager Tables 160 occupy a total of 
192 KBytes (48 pages). The 48 pages in which the Compression Manager 
Tables 1 60 are stored, plus the first two pages assigned to the lowest addresses 
of the Compression Heap 124, are unswappable pages that must be Icept in 
primary memory at all times. 

25 

Figure 4 shows the virtual memory Page Table 146 used by the virtual memory 
unit VMU 1 1 0 (see Figure 2) to translate virtual addresses into physical memory 
addresses. The Page Table 1 46 is stored in RAM and includes one Page Table 
Entry (PTE) 180 for each defined virtual memory page. The Page Table is 
30 indexed by the most significant bits of the virtual memory address, as detennined 
by the page size. For a computer using 32-bit addresses and 4-KByte pages, 
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the Page Table will be indexed by the 20 most significant bits of each virtual 
memory address. Thus, when the CPU tries to access any specified virtual 
memory address, the VMU will use the 20 most significant bits of that address 
to access a PTE in the Page Table. That 20-bit value is called the page number 

5 

In the prefen-ed embodiment each Page Table Entry 180 occupies 4 bytes and 
includes 20-bft Tag Value 1 82 and 12 status flags, only six of which are discussed 
herein. The 20-bit Tag Value 182 is equal to the 20 most significant bits of a 
physical address when the corresponding virtual memory page Is mapped into 
10 a page of RAM in the Woric Space. Othenvise, the 20-bit Tag Value 1 82 is either 
a Tag Value used by the VM Compression Manager 1 52 to Iceep tracic of where 
the virtual memory page is located in the MappedOut storage space 130, or is 
a void value having no significance (e.g., if the virtual memory page is currently 
unassigned to any program or task). 

15 

Figure 5 represents a single Page Table Entry 1 80. The six status flags relevant 
to the present invention are as follows. The Mappedin (Ml) flag 1 84 is set equal 
to 1 when a virtual memory page is mapped into the Work Space (the 
uncompressed part of primary memory) and set equal to 0 othenvlse. The Tag 
20 Value 182 is a physical RAM address only when Mi=1. 

The Modified (MD) flag 186 of a page is automatically set by the VMU 110 
hardware whenever a write operation is performed to any location in that page. 
The Used (U) flag 1 88 of a page is automatically set by the VMU 1 1 0 hardware 
25 whenever a read or a write operation is performed on any location in that page. 
Thus, the VMU 1 10 stores two types of memory usage information in the Page 
Table. 

The MappedOut (MO) flag 190 is used by the VM Manager 150 of the present 
30 invention to denote pages that have been mapped out of the Wortc Space. Pages 
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whose PTE has MO=1 may be either in the Compression Heap or in secondary 
memory. 

The NoSwap (NS) flag 192 is used by the VM Manager 150 to mark virtual ^ 
5 memory pages that must be kept resident in primary memory. These pages are 
indicated generally in Figure 4. 

The WoricSpaceUsed (WSU) flag 194 is a cumulative use flag used by the VM 
Manager to keep track of all virtual memory pages used during a particular period 
10 of time herein called a Epoch. In the preferred embodiment an Epoch is about 
three seconds long, excluding time spent swapping pages out of the Wortc Space. 



VIRTUAL MEMORY MANAGER 

15 

Referring to Figure 6, the VM Manager 150 includes a number of procedures 
200-21 6 that will be described below. The VM Manager 1 50 maintains two data 
structures 220-222 for storing memory usage information. The LRU table 220 
stores a 16 bit value for each physical RAM page, indicating which pages were 
20 least recently used, and the Best 1 28List 222 is a list of up to 1 28 virtual memory 
pages that are candidates for being swapped out of the Work Space. The VM 
Manager also stores a number of miscellaneous pointers and data values 224 
used to denote that status of various tasks the VM Manager perfonns. 

25 The following is a description of the VM Manager procedures used in a preferred 
embodiment of the present invention. 

Receive Fault - VMM Procedure 

30 Referring to Table 1 , the Receive Fault procedure is the top level procedure for 
processing a received page fault. The Receive Fault procedure receives the 
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page number (Page#) of the virtual memory page on which the fault occurred, 
the page's tag value (tag) and the status flags from the page's Page Table Entry. 

The primary job of the Receive Fault procedure is to call the GetPage procedure 
5 202. which gets a page of RAM to satisfy the fault and maps that page into the 
virtual page address for the Transient Page. If the faulting page has status flags 
Ml=0 and MO=0, that virtual memory page is currently unused, and thus it does 
not need to be swapped in from the MappedOut storage space 130. 

1 0 Normally, the RAM page used to satisfy the fault on a page with Ml=0 and MO=0 
must be initialized, typically by filling it with zeros. This is (A) to make the page 
highly compressible if the page is later swapped out, and (B) to make sure that 
data left in the RAM page is not transferred to another application (which is a 
concern mostly in multiprocessing cwriputer systems), i^owever. If the MD status 

15 flag is equal to 1. the page is not initialized because another VM Manager 
procedure (the Read Pending procedure) sets a page's status flags Ml. MD, MO 
» 0, 1,0 only when that page is about to be filed with data from an external 
source, such as a disk or network. 

20 When a page fault occurs on a virtual page that is in the MappedOut storage 
space, the status flags Ml. MD. MO « 0. 0. 1. In this case, after the GetPage 
procedure installs a RAM page into the Transient Page address, the contents 
of the virtual page are retrieved and copied Into this RAM page by calling the 
ReadCompPage procedure. The contents of the previously mapped out page 

25 are then flushed from MappedOut storage by calling the ReleaseCompPage 
procedure. 

Finally, the physical RAM page previously mapped into the Transient Page 
address is mapped into the virtual memory page at which the page fault occure'd 
30 by calling the MapPage procedure 203. 
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Every time a page fault occurSp the ReceiveFault procedure also checks to see 
if the WSU status flags in the Page Table need to be cleared. In particular, each 
time a three second timer called EiapsedEpochTimer expires the WSU flags are 
cleared and the timer is restarted. In addition, whenever a foreground context 
5 change occurs the WSU flags are cleared. The use of the WSU flags will be 
discussed below when the BulldBest128List procedure is explained. 

Get Page - VMM Procedure 

10 Referring to Table 2, the GetPage procedure 202 basically repeats two steps 
until the Compression Manager 152 hands it a free physical RAM page that can 
be mapped into the virtual memory page upon which a fault has occurred. The 
first step is to call the Compression Manager procedure called 
GetCompPage(PageAdr,fail). If the Compression Manager 152 has more than 

15 two pages of free space in its Compression Heap 124, it returns the currently 
virtual address (PageAdr) of a RAM page at the end of the Compression Heap 
124, and a fail flag equal to False. If the Compression Manager has less than 
two pages of free space in the Compression Heap 124, it returns a fail flag equal 
to True. 

20 

If the call to GetCompPage results in the receipt of a RAM page from the 
Compression Manager, the VM Manager procedure GetPage (A) maps that RAM 
page into the page table entry for the Transient Page, and (B) un-maps the RAM 
page from the end of the Compression Heap. 

25 

If the call to GetCompPage results in a fail flag signal from the Compression 
Manager, the VM Manager procedure GetPage calls the SwapOutPage procedure 
204, which swaps one page from the active Work Space to the MappedOut 
storage space, and then the GetPage procedure once again calls GetCompPage 
30 to try to get a free RAM page to map into the virtual memory page upon which 
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a f auK has occurred. GetPage repeatedly calls GetCompPage and SwapOutPage 
until a free RAM page is received from the Compression Manager. 

Each call to the SwapOutPage procedure swaps one of the least recently used 
5 pages in the active Work Space to the MappedOut storage space. Thus» each 
call to SwapOutPage reduces the Work Space by one page. However, the 
Compression Manager attempts to compress each page it receives from the 
SwapOutPage procedure, and thereby generates "free* RAM pages to hand back 
to the VM Manager. For Instance, If the Compression Manager receives two 
1 0 swapped out pages, and compresses each by a ratio of 3: 1 , the two compressed 
pages will occupy just two-thirds of a page, and thus the Compression Manager 
will have generated one and one-third free pages of storage space. 

In one circumstance the SwapOutPage procedure does not swap a page out 
15 to MappedOut storage, and instead hands a RAM page directly over to the 
GetPage procedure. This happens when the page selected by the SwapOutPage 
procedure to swap out is an uninitialized page, which means that while a RAM 
page is mapped into the selected virtual memory page, the virtual memory page 
has not been used. In this case the SwapOutPage procedure returns the virtual 
20 address of this uninitialized page, and GetPage then maps that page into its new 
virtual address (i.e., TransientPageAdr). 

MapPage - VMM Procedure 

25 The MapPage procedure (A) maps the physical RAM page previously obtained 
by the GetPage procedure into the page table entry for the virtual memory page 
on which the fault occurred, and (B) updates the "#UncompressedPages' value 
maintained by the VM Manager to indicate the increased number of pages in 
the Work Space, and then retums control to the ReceiveFault procedure. 

30 
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Swap Out Page - VMM Procedure 

Referring to Table 3, the SwapOutPage procedure 204 makes use of the 
Best128Ust 222. Each time the SwapOutPage procedure is called, a swap 
5 counter. #Swaps. Is incremented and compared with the SwapThreshoId value. 
When tfie #Swaps is greater than the SwapThreshoId, the AgingEvent procedure 
206 is called and the swap counter #Swaps is reset to zero. 

As discussed below, the AgingEvent procedure 206 updates the Best128List, 
10 which is a list of pages that are candidates for being swapped out to the 
MappedOut storage space. The AgingEvent procedure also updates a flag called 
GrowWS. GrowWS is Tnje when the VM Manager has detemiined that the Work 
Space needs more primary memory pages, and is False otherwise. 

15 The SwapOutPage procedure contains a loop that executes repeatedly until a 
page is found that can be swapped out of the Work Space. In the first part of 
the loop a page to be swapped out is selected. This is accomplished by looking 
through the pages listed in the Best12BList. If the GrowWS flag is True, the 
pages listed in the Best128List are inspected and the first page in that list which 

20 has a True Mappedin status flag and a False Used flag is selected. Thus, any 
page in the Best128List which is cun-ently in the Workspace and v«^ich was not 
recently in use is eligible to be swapped out. If the GrowWS flag is False, the 
pages listed in the Best128Ljst are inspected and the first page in that list which 
has a True Mappedin status flag, a False Used flag, but which does not have 

25 Ml .MD.MOsI .0. 1 . Is selected. The logical address of the selected page is stored 
in the variable PG. 

The status flag value MI.MD,MOs1,0.1 is a special status flag combination for 
pages that were previously sent to the Compression Manager and which letumed 
30 by the Compression Manager as being "incompressible". Pages are denoted 
as being incompressible when the Compression Manager is unable to compress 
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the page by more than a predefined percentage, such as 12.5 percent. Pages 
known to be incompressible are swapped out only v^en the GrowWS flag is 
True. 

5 If the entire Best128Ust is inspected and no eligible page for swapping out is 
found, the SwapOutPage procedure calls the BuildBest128List procedure 208, 
which regenerates the Best128LJst based on the cunrent page usage Infonmation. 
The search for a page eligible to be swapped out is then rep>eated through the 
regenerated Best128List. This search will be successful, because the 

10 regenerated Best128List will include only pages whose Used flags are False, 
unless the only pages in the Best128List are pages previously marked as 
Incompressible (which is very unlikely to ever be the case). Since the LRU table's 
usage data for incompressible pages is set to the maximum possible value (FFFF) 
when the SwapOutPage procedure first tries to swap out those pages, such 

15 pages rarely make it back to the Best128Ust. 

However, if the Best12BList still doesnl have any pages eligible for being 
swapped out. the AgingEvent procedure is called, which updates the LRUtable 
upon which the Best128Ust is based and also rebuilds the Best128Ust. The 
20 search through the Best128Ltst for a page eligible to be swapped out is then 
repeated. This process of searching the Best128Ust and calling the AgingEvent 
procedure if no swappable pages are found is repeated until a swappable page 
is selected. 

25 Once a swappable page has been selected, the aging data for the selected 
physical RAM page is set to FFFF. which ensures that this RAM page will not 
t>e selected again in the near future for swapping out again. In addition, If the 
selected page is an uninitialized page, indicated by MI,MD,M0=1 ,0,0. this page 
can be directly remapped to a new location in the virtual address space and does 

30 not need to be sent to the compression manager Thus, when an uninitialized 
page is selected, its current virtual address is stored in the PageAdr return 



BNSDOCIO: <WO_9518997A2J_> 



wo 95/18997 PCT/US94/14987 

•22- 

argument, the EiapsedEpochTimer is reset to the value it had when 
SwapOutPage was called, and the SwapOutPage procedure exits, returning 
control to the GetPage procedure. 

5 The second part of the SwapOutPage control loop is to swap out the selected 
page by calling the WriteCompPage procedure using parameters PG, GrowWS, 
Tag, and Fail, where PG Is the logical address of the page to be swapped out, 
and GrowWS is the flag indicating if the Work Space needs to increase in size. 
Tag is a tag value returned by the Compression Manager that must be stored 
10 in the Page Table in order to be able to recover the swapped out page from the 
MappedOut storage space, and Fail is a flag that is set when (A) the page 
selected to be swapped out is detemrtined to be incompressible and (B) the 
GrowWS flag is False. 

15 The WriteCompPage procedure is allowed to return a Fail value of True only 
when GrowWS is False. If WriteCompPage returns a Fail value of False, the 
page has been stored in the MappedOut storage space and the SwapOutPage 
procedure marks the page as being in the MappedOut storage space by 
(A) storing the retumed Tag value in the Page Table Entry for the swapped out 

20 page, and by storing status flags MI,MD,MOsO,0,1 in the Page Table Entry for 
the swapped out page. In addition, when a page is swapped out to the 
MappedOut storage space, the SwapOutPage procedure decreases the 
#UncompressedPages count value of pages in the Work Space by one. 

25 If WriteCompPage retums a Fail value of True, the SwapOutPage procedure 
marks the page as incompressible by storing status flags MD,MOsO,1 in the Page 
Table Entry for that page. Furthermore, the process of selecting a page to swap 
out and then attempting to swap out that page is repeated until a page is 
successfully swapped out to the MappedOut storage space. 

30 
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The ElapsedEpochTime timer is reset at the end of the SwapOutPage procedure 
to the time value it had when the SwapOutPage was called, thereby removing 
time spent in the SwapOutPage procedure from the measurement of the elapsed 
time for each work space usage epoch. 

5 

Aging Event - VMf^ Procedure 

The LRU table 220 contains one 16-bit value for each physical RAM memory 
page. The data in the LRU table 220 is generated by shifting the Used status 

1 0 bits (U) from the Page Table Into the LRU table at a rate such that the contents 
of the LRU table are completely replaced each time the number of swapped out 
pages equals the number of pages in the Work Space. If the number of 
uncompressed pages (#UncompressedPages) in the Work Space is 2048, then 
the SwapOutPage procedure generates a SwapThreshold value of 2048/16 s 

15 1 28 swaps. When the number of calls to the SwapOutPage procedure exceeds 
this SwapThreshold, the SwapOutPage procedure calls the AgingEvent procedure 
206. 

Referring to Table 4, the AgingEvent procedure 206 makes one pass through 
20 the Page Table 1 46 to collect the Used status bits in all the virtual memory pages 
that are cunrently mapped into the Work Space. Thus, pages that are designated 
as being unswappable by a NS status flag equal to 1, pages In MappedOut 
Storage and uninitialized non-resident virtual memory pages are ignored. For 
each virtual memory page in the Work Space, the physical RAM page number 
25 is obtained from that page's Page Table Entry. That RAM Page number is then 
used as an index to access an entiy in the LRUtable 220, and that entry in the 
LRUtable is updated by right shifting the Used status bit of the virtual memory 
page In the LRUtable entry. Thus, the least significant bit of the LRUtable entry 
is discarded and the most significant bit of the LRUtable entry is set equal to 
30 the Used status bit. 
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From the above it can be seen that the pages least recently used will have the 
smallest values stored in the LRUtable. 

In addition, for each virtual memory page in the Work Space, (A) the Used status 
5 bitfrom the Page Table Entry is logically ORed with the Work Space Used status 
bit (WSU) and stored as the updated WSU status bit in the Page Table Entry. 
(B) the Used status bH is cleared, and (C) a variable called #PagesUsed is 
Increased by 'I' If that page's WSU status bit is equal to 'I'. The variable 
#PagesUsed represents the number of swappable virtual memory pages that 
10 have been accessed since the last time all the WSU status bits were reset. 

As the data in the LRUtable is updated, the AgingEvent procedure also 
regenerates the Best128Llst. The Best128List 220 is a table having 128 slots 
for storing virtual page numbers, plus a count #BestEntries indicating the number 
15 of entries in the Best128List, and an age value BestAge, indicating the value 
in the LRUtable for the pages listed in the Best128List. 

When the AgingEvent procedure begins, the #BestEntries variable is set to zero 
and the BestAge is set to FFFF. Each time an LRUtable entry is updated, the 

20 LRUtable value is compared with the BestAge value. If the LRUtable entry is 
less than the BestAge. the Best128List is restarted by setting BestAge to the 
LRUtable entry's value, storing the current virtual page number If the first slot 
of the Best128List, and by setting the #BestEntries to 1 . If the LRUtable entry 
is equal to the BestAge, the current virtual page is added to the Best128List by 

25 storing its virtual page number in the slot of the Besti 28List designated by the 
#BestEntries value, and by then increasing the #BestEntries by 1. 

Finally, after all the virtual memory pages have been processed and the 
Besti 28List regenerated, the GrowWS flag is regenerated by setting this flag 
30 to True if the value of #PagesUsed (computed by the AgingEvent procedure) 
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is greater than the value of #UncompressedPages (which is the number of 
swappable pages in the Work Space). 

The order in which the Page Table Entries in the Page Table are processed by 
5 the AgingEvent procedure affects the order in which virtual pages are represented 
in the Besti 2BList. To prevent any bias for swapping out pages in any particular 
portion of the virtual address space, the AgingEvent procedure maintains a 
pointer. StartSweepPtr, that is shifted by one Page Table Entry each time the 
AgingEvent or BuildBest128Ust procedure is called. The StartSweepPtr 
10 designates the page table entry at which the sweep through the Page Table 
begins for updating the LRUtable and for regenerating the Besti 28List. 

Build Best 128 List - Vf^M Procedure 

. 15 Referring to Table 5, the BuildBest12BList procedure 208 is virtually the same 
as the AgingEvent procedure 206, except that the BuildBest128List procedure 
does not update the aged memory usage data in the LRUtable and does not 
clear the Used status bits in the Page Table, in addition, if the Besti 28List 
generated by the BuildBest128Ust has zero entries (which can happen if all pages 

20 in the Work Space have been used since the last time the Used status flags were 
cleared by the AgingEvent procedure), the BuildBest128List procedure calls the 
AgingEvent procedure to update the LRUtable, clear the Used status bits in the 
Page Table, and then rebuild the Besti 28List of potentially swappable pages. 

25 Read Pending • VMM Procedure 

Referring to Table 6, the Read Pending procedure is called each time a Read 
from an extemal source occurs. A Read operation occurs whenever a disk read 
occurs, or a read from another I/O port is performed. The Read Pending 
30 procedure provides special handling for pages of virtual memory in MappedOut 
Storage that are about to be ovenvritten by data from an i/O device, in particular, 
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if the virtual memory page that is about to receive data from an I/O read has 
MI.MOsO.I , there is no point in restoring the page of data stored in MappedOut 
Storage,, because that data is about to be overwritten. The Read Pending 
procedure (A) releases the previously stored virtual memory page from the 
5 MappedOut store by calling the ReleaseCompPage procedure, and (B) stores 
status flags of MI,MD,MOsO,1,0 in the Page Table Entry for each of the pages 
that the read operation will entirely fill with data. This status flag setting is a 
special marker indicating that the virtual page need not be initialized when a new 
RAM page is mapped into this virtual memory page, because it will be filled with 
10 data from an upcoming read operation. 

The Read Pending procedure also clears the MD and MO bits for all virtual 
memory pages that are currently mapped into the Work Space that are about 
to receive data from an i/0 read so as to indicate that these pages are mapped 
15 in, but uninitialized. Clearing the Modified status flag (MD) also helps to ensure 
that the contents of these pages does not get stored in the MappedOut storage 
sfDace before the read operation is completed. 

After these Page Table operations are performed, processing returns to the 
20 operating system read procedure that normally handles read operations. 

Deallocate Pages and Deallocate Memory Range - VMM Procedures 

Virtual memory pages are typically deallocated when an application temninates, 
25 or when an application completes a task and releases the memory used for that 
task. Like the Read Pending procedure described above, the VM Manager^s 
DeallocatePages procedure perfonns special Page Table operations to ensure 
proper handling of page deallocations. In particular, referring to Table 7, when 
pages in MappedOut Storage are deallocated, the DeallocatePages procedure 
30 releases the previously stored virtual memory page from the MappedOut store 
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by calling the ReleaseCompPage procedure, and (B) stores status flags of 
MD.MO.U and WSU=0,0«0,0 in the Page Table Entry for release page. 

The Page Table Entries for deallocated pages mapped into the Work Space are 
5 modified by setting the MD, MO, U and WSU status bits to zero, in addition, 
these deallocated pages are filled with zeros (or any other repeating word value) 
to malce the page highly compressible. For instance, if the page is later reused, 
but only a small portion of the page is used before it is swapped out. the unused 
portions of the page will be very highly compressible because the page was 
10 pre-filled with compressible data (i.e., cleared) upon its prior deallocation. Finally, 
a value of 0000 H is stored in the LRUtable entry for the deallocated pages, 
thereby making the RAM pages in which these virtual memory pages are stored 
highly eligible for reuse. 

15 Address ranges not beginning and ending on page boundaries can t>e deallocated 
at any time by application and system programs for a wide variety of reasons. 
The DeallocateMem procedure fills any partial pages in the deallocated address 
range with compressible data (e.g.. zeros), and calls the DeallocatePage 
procedure (discussed above) to handle the deallocation of any complete pages 

20 in the deallocated address range. 

VMM Initialization Procedure 

Referring to Table 8, the VMM Initialization Procedure is executed during or at 
25 the end of the computer's boot sequence. This procedure extends the Page 
Table to include the virtual memory address space needed for the Work Space 
and for the Compression tables and Compression i-leap. It also installs the VM 
Manager, VM Compression Manager, and the Compression Manager Tables, 
assigns an initial set of RAM pages to the Compression Heap, and assigns all 
30 remaining RAM pages to the next logical addresses to be assigned by the 
operating system. 
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In multiprocessing implementations, the remaining RAM pages would be added 
to the end of the Corripression Heap, which acts as a RAM page free list. 

The NS, U and WSU status flags in the Page Table are initialized tp indicate 
5 the unswappabte pages used by the VM Manager and VM Compres^on Manager 
and to dear the Used and WorkSpaceUsed status flags in all Page Table Entries. 

The LRUtable Is cleared and the Best128Llst is initialized by storing therein a 
list of 128 pages that have been mapped into the Work Space, but not yet 
10 initialized. The GrowWS flags is initially set to False, the ElapsedEpochTime 
is set to zero and the ElapsedEpochTime timer is started. 

VM COMPRESSION MANAGER 

15 

We will first explain the primaiy data structures used by the Compression 
Manager, and then will explain the primary procedures used by the Compression 
Manager to compress, store and retrieve pages from MappedOut storage. 

20 Referring to Figures 9-13, the Compression Manager uses a variable amount 
of secondary memory to store Mapped Out pages for which there is insufficient 
room In the Compression Heap 124. When the user accessible virtual memory 
address space is equal to twice the size of the physical primary memory, it is 
unusual for any pages to need to be swapped out to secondary memory. 

25 However. If most of the contents of the virtual memory address space is highly 
Incompressible, it would be possible for MappedOut storage to occupy an amount 
of space in the secondary memory that is equal to the size of the physical primary 
memory. In the preferred embodiment, the Compression Manager initially creates 
only a small disk file for storing MappedOut pages, and then grows that file as 

30 necessary. 
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Referring to Figure 10. the Sector Table 162 is sized so that It can store one 
used/unused flag value 230 for each sector of secondary (disk) memory that 
the MappedOut storage space could potentially occupy. A sector of secondary 
memory in the preferred embodiment stores 512 bytes of data, and thus 8 sectors 
5 would be needed to store a 4096 byte page of uncompressed data. In a system 
with 8 MBytes of RAM. the Sector Table 162 contains 64K entries 230 for 
indicating the used/unused status of up to 64K secondary memory sectors. 

Every page stored in MappedOut storage is assigned a unique tag value between 
10 1 and #VMPages-1 , where WMPages is the maximum number of user accessible 
virtual memory pages. A Tag value of zero is never assigned to a MappedOut 
page. 

The Main Mao. 

15 Referring to Figure 1 1 . the Main Map table 172 contains one 6-byte entry 232 
for each possible tag value. Each entry 232 in the Main Map 172 includes a 
2-byte compression size parameter CompSize, and a 4-byte pointer. The 4-byte 
pointer normally stores the logical address of the location in the Compression 
Heap in which the page is stored (actually the location of the end of the first data 

20 segment in the Compression Heap in which the page is stored, as will be 
explained in more detail below). When a page is stored in secondary memory, 
its Main Map pointer is set equal to -I. 

Certain special values of the CompSize parameter are used to indicate 
25 MappedOut pages having a special status. In particular, when CompSize » 4096, 
this means that the MappedOut page is being stored in uncompressed form, 
(e.g., because the Compressor was unable to compress this page). When 
CompSize a -1 , this means that all 1 6-bit words in the page are identical in value, 
in which case the page is not stored in the Compression Heap 124, and instead 
30 the value of the repeated 1 6-bit word is stored in the bottom 2-bytes of the Main 
Map pointer for that page. Finally, when CompSize is less than or equal to 1 024, 
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this means the page was compressed by a factor of at least 4:1 Jn which case 
the page will never be swapped out to the secondary memory. 

The Map Chain, 

5 Refening to Figure 1 2, the MapChaIn table 1 74 stores data indicating the order 
in which the pages in the Compression l-ieap were added to MappedOut storage. 
The MapChain table stores a doubly linked list of MappedOut pages, based on 
their tag values. In particular, the MapChain table 1 74 contains one 4-byte entry 
234 for each possible tag value. Each entry 234 in the MapChain table 172 
10 includes a 2-byte Back Pointer and a 2-byte Forward Pointer. The Back and 
Forward Pointers for a particular MapChain entry 234 contain the tag numbers 
of MappedOut pages before and after the page corresponding to that MapChain 
entry. 

1 5 Two additional pointers, MapChainStart and MapChainEnd are used to indicate 
the first and last pages currently included in the MapChain. 

When a page is removed from MappedOut storage or is moved to secondary 
storage, it is removed from the MapChain table 174 using the 

20 RemoveFromMapChain procedure shown in Table 14. In addition, the pointer 
for the page in the MapChain is set equal to -1 (to indicate the page is stored 
in secondary memory) and a pointer to the first sector in the secondary memory 
in which the page is stored is then stored in the MapChain entry for that page. 
Thus, the pages at the beginning of the MapChain are the pages added to the 

25 Compression l-leap 124 the longest ago, and thus are the best candidates for 
being moved to the secondary storage should it become necessary to shift some 
MappedOut pages to secondary storage. 
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The Compression Heap. 

Referring to Figure 1 3, the Compression Heap 124 is organized as follows. The 
Compression Heap 124 always contains at least two pages of storage space 
and the pages in the Compression Heap are outside the virtual address space 
5 accessible to application programs. The Compression Manager maintains a 
pointer, EndHeap, to the virtual address location just past the end of the 
Compression Heap. The Compression Heap is divided into variable size data 
"segments* 240 (which contain data from pages, usually in compressed form) 
and Free Space segments 242. initially, the entire Compression Heap is a single 
10 Free Space segment. As pages are added to the Compression Heap, each page 
is allocated just enough space to store that page (usually in compressed iorm) 
in the Compression Heap. Whenever a page in the Compression Heap is 
released or returned to the Work Space, its space is added to the set of Free 
Space. 

The set of Free Space segments 242 are maintained as a doubly linked list that 
is sorted in logical address order. Thus, each Free Space segment 242 in the 
list is located at a higher logical address than the Free Space segment next lower 
in the list. Two pointers, FirstFree and LxistFree point to the first and last Free 
20 Space segments. 

As shown in Figure 13, each Free Space segment contains a 4-byte Back Pointer, 
to the preceding Free Space segment in the list (if any), a 4-byte Forward Pointer 
to the next Free Space segment in the list (if any), a 4*byte size parameter that 
25 specifies the number of bytes in the Free Space segment, and an end-of segment 
4-byte mariner equal to 0000 0000 H at the end of the segment. The Back and 
Forward Pointers in the Free Space segments point to the beginning of other 
Free Space segments. 



BNSDOCID: <WO ^9Sie997A2_l_> 



wo 95/18997 



PCT/US94/14987 



•32- 

The minimum size of a Free Space segment is 16 bytes. If a Free Space 
segment is 20 bytes or larger, its size parameter Is repeated in the 4-bytes 
preceding the ehd-of-segment marker. 

5 Each data segment contains a 4-byte Link at its end, preceded by a 2-byte Size 
parameter, which indicates the size of the data segment in bytes. When a page 
is stored as a set of linked data segments in the Compression IHeap, the Link 
at the end of each data segment, other than the last data segment, points to 
a location 6 bytes before the end of the next data segment for that page. The 
10 Link of the last data segment for the page stores the 2-byte tag value for the 
page, for reasons that will be explained below. 

The Compression Manager includes the following procedures. GetCompPage 
250 is a procedure called by the VM Manager to get a free RAM page to satisfy 

15 a page fault. FillFromBottom 252 is a procedure called by GetCompPage 250 
when the Compression Heap has enough free space that the Compression 
Manager can give a free RAM page to the VM Manager, but not enough of that 
Free Space is located at the end of the Compression Heap to enable the 
Compression Manager to give the last page in the Compression Heap back to 

20 the VM Manager. 

WriteCompPage 254 is a procedure called by the VM Manager to write a page 
in the Work Space into MappedOut Storage. ReadCompPage 256 is a procedure 
called by the VM Manager to copy a page in MappedOut storage into a page 
25 in the Work Space. ReleaseCompPage 258 is a procedure called by the VM 
Manager to delete a page from the MappedOut Storage. RemoveFromMapChain 
260 is a procedure called by the ReleaseCompPage procedure to delete a 
specified page from the chain of pages in the MapChain table 174. 

30 Compress 262 and Decompress 264 are the procedures for compressing a 
specified page of data and for decompressing a specified page of data, using 
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a version of the Lempel-Zif data compression technique optimized for execution 
speed. 

c^iA/apQutFlag. FreeHeaoBvtes. etc.. 
5 The SwapOutFiag is a copy of the last GrowWS flag received from the VM 
Manager. When the SwapOutFiag is True, the Compression Manager stores 
MappedOut pages on secondary memory (A) whenever that is necessary to 
satisfy "GetPage" requests from the VM Manager, and also (B) whenever the 
VM Manager sends the Compression Manager an incompressible page to 
10 compress and store. 



FreeHeapBytes is the variable maintained by the Compression Manager to Iceep 
track of the number of bytes available in the Compression Heap for storing 
Mapped Out pages. 

15 

Get Compressed Page - Compression Manager Procedure 

Referring to Table 9, the GetCompPage procedure has four primary sections. 
In the first section of GetCompPage. the procedure checks the amount of Free 

20 Space in the Compression Heap and the total size of the Compression Heap. 
The GetCompPage procedure will retum a fail signal to the VM Manger (A) if 
the SwapOutFiag is False and the Compression Heap has less than 2 free pages 
of Free Space, or (B) if the SwapOutFiag is True and the total size of the 
Compression Heap is less than three pages (because the Compression Heap 

25 must always retain at least two pages of RAM). If either of these failure modes 
occurs, the GetCompPage procedure returns control to the VM Manager and 
does not perform the next three sections of the procedure. 

In the second section of the GetCompPage procedure, if the Free Space in the 
30 Compression Heap is less than two pages and the SwapOutFiag is True, the 
GetCompPage procedure successh/ely moves pages from the beginning of the 



wo 95/18997 



PCT/US94/14987 



-34- 

MapChain to secondary memory until the Free Space in the Compression Heap 
is greater than two pages (i.e., FreeHeapBytes > 2 x PageSize). To do this, 
this second section of GetCompPage repeatedly performs the following functions, 
until Free Space in the Compression Heap is greater than two pages: 
5 1 ) Select the first page listed in the MapChain table 174, and determine 

its size from the CompSize value stored for that page in the Main Map 172. 

2) Inspect the SectorMap table 1 62 to find the first contiguous set of 
available sectors sufficiently large to store the selected page. 

3) Copy the page to the selected region of secondary memory. 
10 4) Add the data segments in which the page was stored in the 

Compression Heap to the list of Free Space segments, updating Free Space 
segment links and the FirstFree pointer, as necessary. If any new Free Space 
segment is adjacent a pre-existing Free Space segment, the adjacent new and 
pre-existing Free Space segments are merged. 
15 5) Update the Main Map and Map Chain to store in the Map Chain 

entry for the page a pointer to the first sector in which the page was stored. 

6) Update the FreeHeapBytes variable to indicate the amount of Free 
Space in the Compression Heap. 

20 The second section of GetCompPage, described above, is skipped if the Free 
Space in the Compression Heap is already greater than two pages. 

After the second section of GetCompPage has been performed or skipped, the 
third section of GetCompPage checks to see if the size of the last Free Space 

25 segment 242 in the Compression Heap is smaller than one page plus 1 6 bytes 
• which is the minimum size needed to ensure that the Compression Heap still 
has a Free Space segment at its end after a page at the end of the Compression 
Heap is given to VM Manager. If the size of the last Free Space segment 242 
is less than this size, the FillFromBottom procedure (which moves data segments 

30 from near the end of the heap to the top of the Free Space) is called, repeatedly 
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if necessary, until the size of the last Free Space segment 242 in the 
Compression Heap is at least one page plus 16 bytes. 

The fourth and last section of GetCompPage computes the logical address of 
5 the last page in the Compression Heap (which will be returned to the VM 
manager), updates the EndHeap pointer by moving it back one page, and 
decreases the size of the Free Space by subtracting the PageSize from the 
FreeHeapBytes variable. Then GetCompPage returns control the VM Manager. 

10 Fill From Bottom - Compression Manager Procedure 

Referring to Table 10 and Figure 13. the FillFromBottom procedure increases 

the size of the last Free Space segment at the end of the Compression Heap. 

This is accomplished by perfomning the following steps: 
15 1) Find the last data segment in the Compression Heap by looking 

at the Tag stored at the end of that data segment (which is located 2 bytes before 

the beginning of the last Free Space segment). 

2) Using the Tag, look up the location of the first data segment for 

that page in the Main Map, as well as the size of the page. 
20 3) Copy the entire page from the Compression Heap 124 into the 

compression buffer 170. 

4) Add the data segments in which the page was stored in the 
Compression Heap to the list of Free Space segments, updating Free Space 
segment links and the FirstFree pointer, as necessary. For each new Free Space 

25 segment that is adjacent a pre-existing Free Space segment, the adjacent new 
and pre-existing Free Space segments are merged. Update the FreeHeapBytes 
variable to reflect the data segments added to the Free Space, as well as Free 
Space created by merging adjacent Free Space segments. 

5) Copy the page from the compression buffer 1 70 to the top of the 
30 Free Space (starting at the first Free Space segment), updating the FirstFree 
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pointer and the Free Space segment links to maintain a doubly linked list of Free 
Space segments in the Compression Heap. 

6). Update the MainMap, if necessary, to indicate the new Compression 
Heap location of the page that was moved to the; top of the Free Space. 
5 7) Update the FreeHeapBytes variabie to indicate the space occupied 

by the moved page. Also, if the Free Space segment into which the end of the 
page was copied was split into a data segment and a Free Space segment, the 
FreeHeapBytes variable Is decreased by 6 bytes to reflect the amount of space 
occupied by an additional segment link. 
10 8) Update the LastPree pointer to point to the beginning of the last 

Free Space Segment (which will now start at a lower address than previously), 
and then return control to the GetCompPage procedure. 

Write Compressed Page - Compression Manager Procedure 

15 

Referring to Table 1 1 , each call to the WriteCompPage procedure 254 Includes 
the following parameters: a page address specified by the calling procedure, 
the GrowWS flag from the VM Manager, a Tag variable in which the Compression 
Manager should retum the tag assigned to the page being written to MappedOut 
20 storage, and a fall flag which the WriteCompPage sets to True under certain 
circumstances. 

The WriteCompPage procedure copies the GrowWS flag in the procedure call 
to the SwapOutFlag and then calls the Compression procedure to compress the 
25 data in the page specified by the calling procedure. The Compression procedure 
stores the compressed page in the Compression Buffer 170 and returns a 
CompSize parameter indicating the numt>er of bytes occupied by the compressed 
page. 

30 If the size of the compressed page indicates that it is incompressible (i.e., the 
page size was reduced by less than a predefined percentage, such as 12.5 
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percent) and the SwapOutPage flag is False, the specified page is not stored 
in MappedOut storage and a fail signal is returned to the calling procedure. 

If the page was not incompressible, or the SwapOutPage flag is True, the 
5 specified page is assigned a Tag value not used by any other page, and the 
size (CompSize) of the compressed page is stored in the size field of the 
associated Main Map entry. 

Next, if the page was incompressible, the SwapOutPage flag is True, and the 
10 amount of Free Space in the Compression Heap is less than two pages, then 

the incompressible page is stored directly in secondary memory in uncompressed 

format, by prefonming the following steps: 

1 ) inspect the SectorMap table 1 62 to find the first contiguous set of 

available sectors sufficiently large to store the selected page. 
15 2) Copy the uncompressed page to the selected region of secondary 

memory. 

3) Store the size of the uncompressed page in the size field of the 
associated Main Map entry, store a -1 value in the Main Map pointer field, and 
store in the Map Chain entry for the page a pointer to the first sector in which 

20 the page was stored. 

4) Add the RAM page in which the selected page was stored to the 
end of the Compression Heap. 

5) Update the FreeHeapBytes variable by one page to indicate the 
increased size of the Compression Heap, and update the EndHeap pointer to 

25 point to the new end of the Cornpression Heap. 

If the CompSize parameter returned by the Compression procedure is equal to 
*1, this means that all 16-bit words in the page are identical in value, in which 
case the page is not stored in the Compression Heap 1 24, and instead the value 
30 of the repeated 16-bit word is stored in the bottom 2-bytes of the Main Map 
pointer for that page. 
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Next. If the CompSize parameter indicates the page was compressible, but not 
filled with identical words, the compressed page is copied from the Compression 
Buffer into the Free Space In the Compression Heap. On the other hand, if the 
CompSize parameter indicates the page was incompressible, and SwapOutPage 
5 is False, then the page is copied in uncompressed format from its current RAM 
page into the Compression Heap and the page size stored in the f^ain Map entry 
for this page is reset to be equal to the size of one page. In either case, the 
location of the page in the Compression Heap is stored in the MalnMap entry 
for the page. 

10 

Next, if the compression ratio for the page stored in the Compression Heap is 
less than 4:1 (meaning the compressed page is larger than 1024 bytes in the 
preferred embodiment), the page is added to the end of the Map Chain by adding 
the appropriate pointers to the corresponding Map Chain entries, in the preferred 
1 5 embodiment of the invention, when a page is compressed by a factor of at least 
4:1 . it will never be swapped out to the secondary memory because it would be 
inefficient to do so. 

Finally, the RAM page in which the specified page was stored is added to the 
20 end of the Compressiori Heap, and the FreeHeapBytes variable is updated to 
indicate the amount of free space in the Compression Heap. 

Read Compressed Page - Compression Manager Procedure 

25 Referring to Table 1 2, the ReadCompPage procedure 256 retrieves a page from 
MappedOut storage, decompresses it If necessary, and stores the retrieved page 
in the virtual memory page specified by the calling procedure. The calling 
procedure specifies both the Tag value of the page to be retrieved, and the virtual 
memory page into which it is to be copied. 

30 
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The procedure starts by reading the page's size and location pointer from the 
Main Map. 

If the page size Is -1 , the specified virtual memory page is filled with the 2-byte 
5 value stored in the location pointer field, the Main Map entry for the page is 
updated by setting its size and pointer to 0, and then the procedure exits, 
retuming control to the calling program. 

If the page size Indicates that the page was not compressed, then it is copied 
1 0 from either the Compression Heap or Secondary memory, as appropriate, directly 
to the Transient Page 1 58 (see Figure 3). 

Retrieving Compressed Pages. 

If the page size indicates that the page was compressed, then it is copied from 
15 either the Compression Heap or Secondary memory, as appropriate, to the 
Compression Buffer 170. If the compressed page was stored in secondary 
memory, the Sector Table is updated to indicate the sectors no longer occupied 
by stored data. 

20 Regardless of whether the compressed page was copied from the Compression 
Heap 124 orthe secondary memory, after it is copied into the Compression Buffer 
1 70 the Decompress procedure is called to decompress the page into a full page 
of data (stored at the Transient Page address). 

25 Release Compressed Page - Compression Manager Procedure 

Referring to Table 13, the ReleaseCompPage procedure 258 deletes the page 
specified by the calling procedure from MappedOut storage. The calling 
procedure specifies the virtual memory address of the page to be released. 

30 
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The procedure starts by determining the tag for the specified page and then 
reading the specified page's size and location pointer from the Main Map. 

if the page's f^ainMap pointer value is equal to -1 , the page is stored on disk. 
5 in that case, the Sector Table 1 62 is updated to show as unused those sectors 
in which the page was stored, and the Map Chain entry for the page is cleared. 

if the specified page is stored in the Compression Heap (and thus does not have 
a stored size equal to -1) the specified page is deleted by adding the 

10 Compression Heap segments in which the page was stored to the set of Free 
Space segments, updating the Free Space segment iinics as necessary. If any 
new Free Space segment is adjacent a pre-existing Free Space segment, the 
adjacent Free Space segments are merged. Then the FreeHeapBytes variable 
is updated to indicate the amount of free space in the Compression Heap. In 

15i addition, if the page begin released from the Compression Heap has a 
compressed size that is greater than one fourth a standard page, it is removed 
from Map Chain by calling the RemoveFromMapChain procedure. 

Details of the RemoveFromMapChain procedure are shown in Table 14, but 
20 essentially it is just a matter of removing an item from a doubly linked list and 
then fixing the fonvard pointer in the item in the list (if any) before the removed 
item and the back pointer in the item (if any) after the removed item so that the 
before and after items are property linked. 

25 Finally the Main Map entry for the specified page is updated by setting its size 
and pointer to 0, and then the procedure exits, returning control to the calling 
program. 

DATA COMPRESSION AND DECOMPRESSION PROCEDURES 

30 
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Referring to Figures 14, 15 and 16 and Tables 15 and 16, the Compress 262 
and Decompress 264 procedures are the procedures for compressing a specified 
page of data and for decompressing a specified page of data, using a version 
of the Lempel-Zif data compression technique optimized for execution speed. 

5 

The Compression procedure makes use of the LastUse table 1 66 and Index table 
168. Referring to Figure 14, the LastUse table 166 is a table with 64K 2*byte 
entries, one for every possible value of a 16-bit word. Each page to be 
compressed contains 2048 1 6-bit words. As each word of the page is processed, 
1 0 starting with the first word, the position of that word is stored in the LastUse table: 

LastUse(word value) s position of word in the page 

where the position value stored in the LastUse table is the position of the first 
15 byte of the word (i.e., an even number between 0 and 4094). 

Refem'ng to Figure 15, the IndexTable 168 stores one entry, containing two 2-byte 
fields, for each of the 2048 words in the page to be compressed. The first field 
of the entry indicates the most recent position in the page, if any, that the same 
20 word was previously encountered. The second field of the entry stores the 
dictionary index for the word at the page position con^esponding to this IndexTable 
entry. 

An explicit dictionary is not constructed during the data compression procedure, 
25 but each time a new unique word is encountered in the page being compressed , 
it is assigned a new dictionary index value and that value is stored in the Index 
Table. The first word in the page is always assigned a dictionary index equal 
to 0. The dictionary for the page can be reconstructed by inspecting the contents 
of the IndexTable 168 and the page being compressed. 

30 
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Compression Procedure 

Referring to Table 1 5 and Rgures 1 4-1 6» the compression procedure 262 works 
as follows. In a first pass through the page to be compressed, the LastUse table 
5 entries for all the words in the page are set equal to -1 (box 270 in Figure 16). 
In addition, if any word is not equal to the preceding word in the page, a flag 
that was initially set to True is reset to False. Thus, at the end of the first pass 
through the page, the relevant portion of the LastUse table needed for processing 
the current page is initialized, and the previously mentioned flag value is True 
10 only if all the words in the page are identical. 

If all the words in the page to be compressed are identical (box 272), then the 
compressed size parameter, CompSize, for the page Is set equal to -1 , and the 
procedure exits (box 274). returning control to the calling procedure. Othenvise, 
15 a second pass through the words in the page is performed. 

In the second pass through the page, the contents of the page are compressed, 
with the resulting compressed data being written into the Compression Buffer 
170. As each word of the page is processed, the pointer value in the LastUse 
20 table for that word is retrieved 

PriorPos ss LastUse(word) 

and checked to see if it is equal to -1, indicating the word has not previously 
25 occurred In the page (box 276). If so, the word is assigned the next available 
dictionary index (boxes 278. 280, 282), which is stored in the IndexTable:, 



lndexTable(Position).lndex = Nextlndex 
Nextindex s Nextlndex 1 . 

30 
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Aiso stored in the IndexTable is a "prior position' value of -1 . indicating the word 
was not previously used in this page: 

indexTabie(Position)PriorPos = -1. 

5 

if the word at the current position did not occur previously in the page, but has 
a value within a range of ± 1 023 of the word four bytes eariier in the page (box 
284), the new word is encoded (box 280) as a *new word differential" code: 

10 '110" + Dif 

where indicates the concatenation of two binary strings, and Dif is the 
difference between the current word and the word four bytes eariier in the page. 
Dif is encoded as an eleven bit, signed value. Audio data and many other types 
1:5 of data used in computers have a strong correlation with the stored a fixed 
number of bytes eariier in memory, and the present invention's compression 
technique takes advantage of this correlation by preferentially encoding such 
16-bit words with a 14-bit encoded value. 

20 If the word at the current position did not occur previously in the page, and does 
not have a value within a range of ± 1023 of the word four bytes eariier in the 
page, the new word is encoded (box 278) as the following 17-bit 'new word" code 
value: 

25 -O* + Word, 

Processing for Word Already in the Dictionary. 

If the word being processed did previously occur in the current page, the LastUse 
entry for that word value 

30 

PriorPos = LastUse(Word)) 
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will be a pointer to the last previous use of that word In the page. The PriorPos 
pointer is then used to access the IndexTable entry for that prior use of the same 
word, and the dictionary index stored in the IndexTable for the prior use of the 
same word Is copied into the dictionary index field for the current word position. 
5 The PriorPos value obtained from the l^tUse table is copied Into the 'most 
recent prior use* field of the IndexTable for the current word position, and then 
the LastUse pointer for the current word is updated to point to the current word 
position (box 286). 

1 0 Next (still box 286), the compression procedure looks for the longest string eariier 
in the page (but not starting more than 32 occurrences ago of the current word) 
that matches the string of words starting at the current position in the page. If 
a matching string of 32 words is found, no further searching for a better match 
is performed, since the maximum length matching string that can be encoded 

15 in the compressed data is 32 words long. The length of the best matching string 
is stored in a variable called BestRun, and the position of the first word in the 
best matching string is stored in a variable called BestPriorPos. 

Best Matching Prior String has a Run Length of 1. 
20 If the longest prior matching string has a BestRun length of 1 , then the current 
word is encoded as a "repeat one word' code and written to the Compression 
Buffer (box 288) as: 

■10" + EIndex 

25 

where EIndex is a variable length index value defined as follows. If Nextlndex 
is the number of words currently in the Dictionary, then the dictionary index for 
the current word is encoded using either N or N-1 bits, where N is equal to 1 
plus the integer portion of the logarithm, base 2, of Nextlndex. In particular, if 
30 the dictionary index for the current word is less than 2^ - Nextlndex, then EIndex 
is equal to the dictionary Index encoded as N-1 bits. Otherwise, EIndex is equal 
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to the dictionary index plus 2^ - Nextindex, encoded as N bits. For instance* 
when the dictionary has 6 entries, the EIndex values for those six dictionary 
entries are: 



5 Pjctignary Index Elntfex 

0 00 

1 01 

2 100 

3 101 
10 4 110 

5 111 



By encoding EIndex with N*1 bits instead of N bits whenever possible, an average 
of about two-thirds of a bit is saved for each use of the "repeat one word" code. 

15 

Best Matching Prior String has a Run Length Greater than 1. 
If the longest prior matching string has a BestRun length greater than 1, then 
the current word and the next BestRun-1 words are encoded as a single "repeat 
prior string" code, using the coding format shown in box 290 of Figure 168. In 
20 addition, the LastUse and Index table values for all the words in the repeated 
string are updated. 

After each word or string of words is encoded, the above procedure is repeated 
starting with the next word of the page (step 292), until all the words in the page 
25 have been processed. The number of bytes of compressed data written to the 
Compression Buffer 170 is stored in the CompSize parameter retumed by the 
Compression procedure to the calling procedure (step 294). 

Decompression Procedure 

30 

Referring to Table 1 6, the decompression procedure works as follows. The data 
to be decompressed is located in the Compression Buffer and the decompressed 
data Is written directly into the virtual memory page specified by the calling 
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procedure. The decompression data comprises a sequence of variable length 
codes that must be decoded in sequence. The first few bits of each code identify 
whether the code is a 'new word" code ("OVword), a "new word differential" code 
("1 10"4.Dif), a "repeat one word" code ClO'+Elndex), or a "repeat prior string" 
5 code ("1 11"-!- BestRun code ^ DistanceBack code). In addition, decoding the 
"repeat one word' code and the "repeat prior string" code requires determination 
of the number of bits used in each such code. 

The decompression procedure also generates and stores In the LastUse table 
10 a dictionary of words used in the page, with the Xth word in the dictionary being 
stored in the Xth entry in the LastUse table. 

To decompress a compressed page, the decompression procedure sequentially 
identifies and processes each code In the page. Once a code is identified, If 

15^ the code is a "new word" or "new word differential" code, the corresponding new 
word Is the added to the dictionary stored in the LastUse table and the count 
(Nextlndex) of the number words In the dictionary is increased. The decoded 
new word Is also written to the specified output page. If the identified code is 
a "repeat one word" code, the specified dictionary entry is written to the specified 

20 output page. If the identified code is a 'repeat prior string* code, the procedure 
determines the position of the first word of the string to be repeated and the 
number of words to be repeated, and then writes a copy of the specified string 
to the specified output page. Then the next code in the compressed page is 
processed. This procedure continues until a full page of uncompressed data 

25 has been generated, at which point the decompression procedure exits and 
retums control to the calling procedure. 

ALTERNATE EMBODIMENTS 



30 
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One preferred alternate embodiment of the present invention is to use a 
co-processor that shares access to the computer's primary and secondary 
memory to perform much of the VM Manager's work, in particular, when the 
co-processor is not occupied by other tasks, it could perform the function of 
5 periodically rebuilding the B6St128List and re-evaluating the WSU flags to 
detemiine when the work space needs to grow. Furthermore, whenever the 
number of free pages in the Compression Heap falls below a threshold number, 
such as six pages» the co-processor could be programmed to select pages from 
the Best12BList and compress and store them in the Compression Heap until 

1 0 the number of free pages in the Compression Heap reached a target level, such 
as twelve pages, thereby making sure that a reasonable number of "free pages" 
are available for use by the VM Manager to satisfy page faults. The co-processor 
would be assigned its own compression buffer, so that both the co-processor 
and the regular Compression Manager executed by the primary CPU can operate 

15 simultaneously. An additional status flag would be needed in the page table 
entries to indicate pages currently being processed by the co*processor, and 
an interiock would be needed so that only one of the two co-processors makes 
changes to the Page Table at any one point in time. 

20 Storing only Decompressed Pages in Secondary Memory 

To speed up the fault response time to faults on pages in secondary memory, 
the present invention could be modified so as to store only uncompressed pages 
in the secondary memory. Thus, when a page is moved from the Compression 
25 Heap to secondary memory, it would first be decompressed and then stored in 
secondary memory. While this would increase the amount of secondary memory 
used, it would not increase the number of times the secondary memory is 
accessed, and it would decrease the fault response time for faults on pages in 
secondary memory. 

30 
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While the present invention has been described with reference to a few specific 
embodiments, the description is illustrative of the invention and is not to be 
construed as limiting the invention. Various modifications may occur to those 
skilled in the art without departing from the true spirit and scope of the invention 
5 as defined by the appended claims. 
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TABLE 1 

© Copyright 1993 Connectix Corporation 
5 Top Level Procedure for Processing a Virtual Memory Fault 

ReGeiveFault(page#,tag,flags) - VMU Fault signal received 

- (A) Get Page to Satisfy the Page Fault 

10 If (MIsO and MOsO) - normally means the faulting virtual address 

is currently unused 

{ 

Call GetPageO - Get physical RAM page to satisfy fault 
lfMD=0 - MI,MD,MO=0,1,0 is a special marking for allocated 

15 page that will be overwritten by data from disk. 

Thus, if MD=1 , we doni bother initializing the page. 

{ 

— Fill page with highly compressible data 
Call FillPage(TransientPageAdr/PageSize) 
20 ) 
} 

Elself (Ml=0 and MOs1 ) — Page is located in compressed storage 

(either in RAM or on disk) 

{ 

25 Call GetPageQ ~ Get physical RAM page to satisfy fault 

~ Retrieve page identified by 'tag* from MappedOut Storage and copy 

it into the allocated RAM page at TransientPageAdr 
Call ReadCompPage(tag) 
Call ReleasePage(page#) 

30 } 

- Map the received page Into the specified virtual memory page 
Call MapPage(page#) 

35 — (B) Check for Foreground Context Switch 

If Foreground Process Context has changed since the last page fault 
— Clear the WSU bit flags used for detemfiing if more pages are 

needed in Workspace 
{ Clear WorkSpaceUsed (WSU) bit flag in all VMPageMap entries) 

40 

- (C) Periodically Update the WorkSpaceUsed (WSU) Flags 

If ElapsedEpochTime > EpochThreshold - Epoch Threshold is nominally 

3 seconds. 

{ 

45 Clear WoricSpaceUsed flag (WSU) in all VMPageMap entries 

Restart ElaspedEpochTime timer at ElapsedEpochTime = 0 

} 

Return 
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TABLE 2 

Procedures for Getting a RAM Page to Use 

5 QetPageO 

Set Flag1 s False 

Do Until (Flag1) - Repeat this Loop until the 

Compression Manager sends a RAM 
page to use 

10 { 

Ask Compression Manager to send one unused RAM page 
Call GetCompPage(PageAdr,fail) 

If failsTrue — Compression Manager did not have an 

unused RAM page to send 
15 {Call SwapOutPage(PageAdr)} Swap one page from RAM to 

MappedOut Storage 
If PageAdr ^0 - Compression Manager did have an unused 

RAM page to send, or the SwapOutPage 
procedure found an uninitialized page to use 

20 { 

— Map the received page into the TranslentPageAdr in the VMU 
page table: 

Set Flagi = True 

page# sTransientPageAdr/PageSize 
25 RecvdPage# sPageAdr/PageSize 

RAM.Adr «VMPageMap(RecvdPage#).Adr 
VMPageMap(page#).Adr =RAM_Adr 
VMPageMap(page#),MI si - Set Mapped In Flag 

— Leave Modified Flag (MD) unchanged 

30 VMPageMap(page#).MO =0 - Reset Mapped Out Flag 

— Un-map the received page from its prior virtual address 
VMPageMap(RecvdPage#).Adr =0 
VMPageMap(RecvdPage#).MI s=0 

35 VMPageMap(RecvdPage#).MD =0 

VMPageMap(RecvdPage#).MO sO 

) 

} - end of Do Until Loop 
40 Return 



FIIIPage(Page#) - Fill page with highly compressible data (could use any 

fill value that is repeated for all wonds in the page) 
45 Fill all words in specified virtual address page with "0000* 

Return 
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MapPage(Page#) 

- Map the received page from the TransientPageAdr into the VMU page 
table: 

RecvdPage# sTransientPageAdr/PageSize 
5 RAM_Adr sVMPageMap(RecvdPage#).Adr 

VMPageMap(page#).Adr =RAM_Adr 
VMPageMap(page#).MI =1 Set Mapped In Flag 

- Leave Modified Flag (MD) unchanged 
VMPageMap(page#).MO =0 - Reset Mapped Out Flag 

10 VMPageMap(page#).U sO - Reset Used Flag 

VMPageMap(page«).WSU sO • - Reset WorkSpaceUsed Flag 



15 



— Update Count of Uncompressed Pages in Workspace 
#UncompressedPages » #UncompressedPages -i- 1 

Return 
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I 

TABLE 3 
Procedure for Swapping Out a Page 
5 SwapOutPage(PageAdr) 

— (A) Preprocessing before each Page Swap Out: 
PageAdr « 0 — Normal return value 
StartTime = ElapsedEpochTime — Store ElaspedEpochTime timer 

10 value for restoration at end of 

swapping procedure 

- LRUtable represents usage history for period in which the number of 
page swaps equals the number of swappable pages in the Work Space 

15 #Swaps = #Swaps -h 1 

SwapThreshold = #UncompressedPages / 16 
If #Swaps > SwapThreshold 
{ 

Call AgingEventO - Updates LRU data table 

20 «Swaps = 0 

} 

(B) Swap Out Control Loop 
Set Fiag2 ^ False 
25 PG»0 

Do Until (Fiag2) - REPEAT until a page is swapped out 
{ 

- (B-1) SELECT A PAGE TO BE SWAPPED OUT 
If GrowWS — Workspace needs to grow 
30 { 

PG s Logical address of page highest on Besti 28List with Mls1 
and U=rO 

) 

Else Workspace does not need to grow 

35 { 

PG = Logical address of page highest on Besti 28List which is 
Mapped In (MIsI) and not cuaently used (U^O), but which 
does not have MI,MD.MOs1.0,1 (- a special marker for 
incompressible pages (compressed less than threshold, e.g.. 
40 1 2.5%)). Doni bother trying to send an incompressible page 

to the Compression Manager unless GrowWS is True 

} 

If PG s 0 - None of the pages in the Besti 28List are 

eligible for being swapped out! Rebuild the 
45 Besti 28Ust: 

{ 

Call BuildBest128Ltst() - Rebuilds Best128 list and updates 

GrowWS flag 
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If GrowWS - Workspace needs to grow 
{ 

PG = Logical address of page highest on Best128 list with 
Mi=1 and U=0 

5 ) 

Else - Workspace does not need to grow 

{ 

PG - Logical address of page highest on Besti 28 list which 
Is Mapped In (Ml=1) and not currently used (UsO), but 
10 which does not have MI,MD,MO=1,0,1 

} 

If PG s 0 - Still no swappable pages In the Best128 list. 
{ - (all pages In Besti 28 list are Incompressible I) 
15 Do Until PG 9^0 

{ 

Call AgingEventQ 

PG s Logical address of page highest on Besti 28 list 
which is Mapped In (Ml=1) and not currently used 
20 (UsO). but which does not have Ml.MD.MO=1 ,0.1 

) 

} 

} 

25 - (B-2) SWAP OUT THE SELECTED PAGE 

- Reset selected page's usage data to FFFF 
RAMPage# « VMPageMAP(PG).Adr 
LRUtable{RAMPage#) « FFFF 

30 ~ If selected page is an uninitialized page, just return it and quit. 

If VMPageMap(PG).MI,MD.MOs1.0.0 
{ 

PageAdr = PG 

~ Restore saved ElaspedEpochTime timer value 
35 Set ElapsedEpochTime s StartTime 

Return 

) 

~ send page PG to Compression Memager for compression 
40 Call WriteCompPage(PG,GrowWS.Tag.fail) 

If fallsTiiie - Page was incompressible (compressed less 

than threshold, e.g.. 12.5%) 
{ - Set VM Page Table Flags with special marker 

45 so that MI.MD.MO := 1.0.1 

Page# = PG / PageSize 

VMPageMap(Page#).MD =0 - Reset Modified Flag 
VMPageMap(Page#).MO ^1 - Set Mapped Out Flag 
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) 

Else 
{ 

— Update VMPageMap for page written to MappedOut Storage 
5 Page# as PG / PageSize 

VMPageMap(Page#).Adr = Tag 
VMPageMap(Page#).Mi s 0 
VMPageMap(Page#).MD = 0 
VMPageMap(Page#).MO » 1 

— Update Count of Uncompressed Pages in WoricSpace 
#UncompressedPages s #UncompressedPages • 1 



10 



Flag2 = True — Page at PG has been successful!/ swapped out 
15 } 

} — end of Do Until Loop 
- Restore saved ElaspedEpochTime timer value 
Set EiapsedEpochTime & StartTime ■ 
Return 
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TABLE 4 

Procedure for Updating LRU Page Usage Data Table 
AgingEventO 

— Simultaneously Update Page Usage Data and Rebuild Best128 Ust 

— Clear Best128 Ust 
BestAge = FFFF H 
#BestEntries s O 
#PagesUsed » 0 

— Do Just One Pass through the VMPageMap 

XP = StartSweepPtr 

StartSweepRr = Rr + 1 Modulo #VMPages 
For Page# » XP to #VMPages and then For Page# s 0 to XP-1 
{ 

- Ignore UnSwappable Pages, Pages In MappedOut Storage, and 

uninitialized non-resident pages 
If ( VMPageMap(Page#).NS - 0 

.and. VMPage(Page#).MI,MD,MO * 0,0,1 

.and. VMPage(Page#).MI.MD.MO ^ 0.0,0 ) 

{ 

- Shift Usage Data into LRUtable 
RAMPage# « VMPageMAP(Page#}.Adr 

RightShift VMPageMAP(Page#).U into LRUtable(RAMPage#} 

~ Update Workspace Usage bits 
VMPageMap(Page#).WSU » VMPageMap(Page#).WSU 

.or. VMPageMap(Page#).U 

- Count Number of Swappable Pages with WSU=1 
If VMPageMap(Page#).WSU 

{ #PagesUsed = #PagesUsed -f 1 } 

- Clear Used Bit Flag 
VMPageMap(Page#).U » 0 

- Update Best126Ust 

If ( LRUtabie(RAMPage#) s BestAge and «BestEntries < 128 ) 
{ 

- Add page to Best128List 
Best128List(#BestEntries) = Page# 
#BestEntries s #BestEntries -t- 1 
) 

If LRUtable(RAMPage#) < BestAge 
{ 
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~ Clear Best128List and Restart with current Page# 
BestAge s LRUtable(RAMPage#) 
Bestl28List(0) = Page# 
«BestEntries s 1 
S ) 
) 

) — End of For Loop 
— Update GrowWS Flag 

10 

~ Note that #PagesUsed equals the number of Pages in Vf^PageMap with 
WSU s 1. excluding UnSwappable Pages (NSsl) and excluding Pages 
whose Page# > #VMPages 

15 If #PagesUsed > #UncompressedPages 

{ Set GrowWS s True } 
Else 

{ Set GrowWS - False } 
20 Return 
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TABLE 5 

Procedure for Building Best128Ust - Ust of Best Pages to Swap Out 

5 BuildBest128Ust() 

— Similar to AgingEventQ procedure, except that Page Usage Data is not 
updated 

10 - Clear Best128 List 
BestAge = FFFF H 
#BestEntries s 0 
WPagesUsed s o 

15 — Do Just One Pass through the VMPageMap 

XP =s StartSweepPtr 

StartSweepPtr = Rr + 1 Modulo #VMPages 
For Page# = XP to #VMPages and then For Page# = 0 to XP-1 
{ 

20 ~ Ignore UnSwappable Pages, Pages in MappedOut Storage, and 

uninitialized non-resident pages 
If ( VMPageMap(Page#).NS s 0 

.and. VMPage(Page#).MI.MD.MO * 0,0,1 
.and. VMPage(Page#).MI.MD,MO ^ 0.0,0 ) 
25 { 

— Update Workspace Usage bits 
VMPageMap(Page#).WSU » VMPageMap(Page#).WSU 

.or. VMPageMap(Page#).U 

30 ~ Count Number of Swappable Pages with WSUsi 

If VMPageMap(Page#).WSU 

{ #PagesUsed s #PagesUsed -i- 1 } 

~ Update Best128List 
35 If (VMPageMap(Page#).U = 0) - Dont put pages currently in 

use into the Best128List 

{ 

If ( LRUtable(Page#) = BestAge .and. «BestEntries < 128 ) 

40 — Add page to Best128List 

Best128List(#BestEntries) s Page# 
#BestEntries s #BestEntries -i- 1 
} 

If LRUtable(Page#) < BestAge 
45 { 

~ Clear Best128List and Restart with current Page# 
BestAge « LRUtable(Page#) 
Besti28Ust(0) ~ Page# 
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#BestEnti1e8 = 1 
) 

} 

) 

5 } - End of For Loop 

- Special Handling if All Pages are In Use 
If #BestEntries « 0 
{ Call AgingEventO } 
10 Else 

- Update GrowWS Fiag 

— Note that #PagesUsed equals the number of Pages in VMPageMap with 
WSU s 1 , excluding UnSwappable Pages (NSsI) and excluding Pages 
whose Page# > #VMPages 

15 { 

if #PagesUsed > WUncompressedPages 

{ Set GrowWS - True } 
Else 

{ Set GrowWS = False } 

20 } 
Return 
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TABLE 6 

Procedure For Handling Read Operation 

5 Read(first.last) 

— An I/O Read from disk or elsewhere is filing all pages from first to last 
For Page# from first to last 
{ 

- Special Handling for pages in MappedOut Storage 
10 If VMPageMap(Page#).MI«^ and VMPageMap(Page#.MO)=1 

{ 

— Compression Manager releases space allocated to this page 
Call ReleaseCompPage(Page#) 

15 - Set Up VMPageMap 

Clear Flags Ml and MO of VMPageMap(Page#) 

Set Flag MD of VMPageMap(Page#) - special marker 

) 

If VMPageMap(Page#).MI » 1 
20 { 

- keep as resident page, but do not bother to initialize 
Clear Flags MD and MO of VMPageMap(Page#) 

} 

) 

25 ) ~ End of For Loop 

Call Standard OS Read() procedure 
Return 
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TABLE7 

Procedures For Handling Memory Range and Page Deallocations 

OeallocateMem(begin.end) - This is called when a program deallocates 

memory from addresses 'begin' to 'end' 
If (the address range 'begin' to 'end' includes any complete pages) 
{ 

first = address of the first complete page in the specified address range 
last s address of the last complete page in the specified address range 
Call DeallocatePages(first.last) 
} 

Rll the deallocated portions of any partially deallocated pages with zeros 
Return 



OeallocatePages(first,last) - This is called when a program terminates 

or deallocates pages no longer needed 

For Page# from first to last 
{ 

— Special Handling for pages in MappedOut Storage 
If VMPageMap(Page#).MIsO and VMPageMap(Page#).MOs1 
{ 

- Compression Manager releases space allocated to this page 
Call ReleaseCompPage(Page#) 

- Set Up VMPageMap 

Clear Flags MO. MD. U and WSU of VMPageMap(Page«) 
) 

If VMPageMap(Page#).MI s 1 
{ 

- Keep as resident page, but ... 

- The Modified (MD) flag is cleared so that this deallocated logical 
page will not be saved to MappedOut Storage 

Clear Flags MD. MO. U and WSU of VMPageMap(Page#) 

Call RIIPage(page#) — Fill page with highly compressible data 

- Set Usage History to 0000 H so that the RAM page can be 
reused 

Clear LRUtable(Page#) 

) 

} — End of For Loop 
Return 
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Table 8 
VM Manager Initialization 

5 InitializeO 

— This procedure is called during standard OS boot sequence 

Extend the VMPageMap to include pages for addresses through 2xPhysMem 
and addresses 40000000 through 40000000 -i- 2xPhysMem 

10 

Install VM Manager, VM Compression Manager, Compression Manager 
Tables 

Assign initial set of RAM pages to Compression Heap 

15 

Assign all remaining RAM pages to the next logical addresses to be 
assigneed by the OS. 

- In mutliprocessing implementations, the remaining RAM pages would 
be added to the end of the Compression Heap, which acts as a RAM 
20 page free list. 

Initialize VMPageMap to indicate UnSwappable pages for VM Manager and 
Compression Manager and to initialize Used and WorkSpaceUsed flags 

25 Initialize Best128Ltst 

Set GrowWS = False 
Set ElapsedEpochTime = 0 
Start ElapsedEpochTime timer 

30 Return 
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COMPRESSION MANAGER PROCEDURE 
Get Free Page from Compression Heap 

5 

GetCompPage(PageAdr,fail) 

— (A) Check Amount of Free Space In Heap 

- If Free Space is < 2 Pages. Compression Manager cannot give a free 
10 page to the VM Manager. 

if ( (FreeHeapBytes ^ 2 x PageSIze) .and. Not(SwapOutFiag) ) 
{ 

failsTrue 
Return 
15 } 

«- If the total size of the Compression Heap is less than 3 pages, this 
means the VM Manager probably has unused pages of RAM mapped 
into unused virtual memory locations, and therefore a Fail signal 
20 is sent to the VM Manager, which will force it to find old unused 

pages to send to the Compression manager. 

HeapSize = EndHeap - BeginHeap 
If HeapSize < 3 x PageSIze 
25 { 

failsTrue 

Return 

} 

30 — (B) If SwapOutFlag is True and Free Space < 2 pages, Generate Free 

Space by Moving Pages from Compression Heap to Secondary 
Memoiy. 

If ( (FreeHeapBytes 2 2 x PageSize) .and. SwapOutFlag ) 
{ 

35 Do Until (FreeHeapBytes > 2 x PageSize) 

{ 

Tag s MapChainStart 

Find SectorPtr to first sector in a sequence of free sectors sufficiently 
40 large to store page PG 

Copy Page associated with Tag from Compression Heap into 
Secondary Memory starting at sector specified by SectorPtr. 

45 Add segments in which the moved Page was stored to set of Free 

Space segments, updating Free Space segment links and FirstFree 
pointer, as necessary. If any new Free Space segment is adjacent 
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a pre-existing Free Space segment, merge the adjacent new and 
pre-existing Free Space segments. 

*- Store Relevant Bookkeeping Data 
5 Update SectorMap to indicate sectors occupied by swapped out page 

MapChainStart = MapCliain(Tag).FonvardPtr 
MapChainfTag) = SectorRr 
MainMap(Tag}.Ptr s-1 

10 FreeHeapBytes s FreeHeapBytes ^ MainMap(Tag).Size 

-f 6 X (Number of segments merged with Free 
Space segments) 
) — End of Do Loop 

) 

15 

— (C) If Size of the Last Free Block is < 1 Page 16 Bytes, move 
compressed data from near the end of the Compression Heap to 
the Free Space closest to the top of the Compression Heap until 
the Last Free Block Is > 1 page 

20 fail=False 

Flags = False 
Do Until (Flags) 
{ 

SizeLastFreeBlock s EndHeap - LastFree 
25 If SizeLastFreeBlock < PageSize + 16 Bytes 

{ Call FillFromBottomO } - Move One Compressed Page 

toward front of Compression l-ieap 

Else 

{ Flags = True} 
30 } End of Do Loop 

— (D) Provide Free Page at end of Compression Heap to VM Manager 

— Compute 32-bit Logical Page Address of Free Page 
PageAdr = EndHeap - PageSize 

35 

— Update EndHeap and FreeHeapBytes 
EndHeap s EndHeap - PageSize 
FreeHeapBytes s FreeHeapBytes - PageSize 

40 Return 
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TABLE 10 

COMPRESSION MANAGER PROCEDURE 
Fill Heap From Bottom Procedure 

FillFromBottomQ 

— Find Last Page in Compression Heap 
LastTag = RAM(FlrstFree - 2) 
HeapLocation e MainMap(LastTag).Rr 
CompSize s MainMap(LastTag).Size 

— Copy Last Page to Compression Buffer 

Copy entire Page from Compression Heap, starting at HeapLocation, into 
Compression Buffer. 

Add segments in which the Last Page was stored to set of Free Space 
segments, updating Free Space segment linlcs and FirstFree pointer, as 
necessary. For each new Free Space segment that is adjacent a pre-existing 
Free Space segment, merge the adjacent new and pre-existing Free Space 
segments. 

— Update FreeHeapBytes 
FreeHeapBytes = FreeHeapBytes + CompSize + 

6 X (Number of segments merged with Free Space segments) 

— Copy Last Page to Top of Free Space 

Copy Page in Compression Buffer into Free Space (starting at First Free 
Space segment) of Compression Heap (starting at First Free Space 
segment), updating FirstFree and Free Space segment iini^s to maintain a 
doubly linked list of Free Space segments in the compression heap. 

Update MainMap, if necessary, to indicate new Compression Heap location 
of the page that was moved to the top of the Free Space. 

— Update FreeHeapBytes 
FreeHeapBytes = FreeHeapBytes - CompSize 

If (the Free Space segment into which the end of the Page was copied 
was split into a data segment and a Free Space segment) 
( FreeHeapBytes s FreeHeapBytes - 6 } 

Update LastFree to point to beginning of last Free Space Segment 



Return 
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Tablell 

COMPRESSION MANAGER PROCEDURE 
5 Write Page into MappedOut Storage Space 



WriteCompPage(PGtGrowWS,Tdg,fa]l) 

10 Update Compression Manager's SwapOut Flag 

(for use by GetCompPage procedure) 
SwapOulFlag = GrowWS 
fail s False 

15 — Call Compression Procedure 

Call Compress(PG,CompSize) 

- Fail if SwapOutFlag is False and page is incompressible 
If (CompSize > Tiireshoid - e.g., 87.5% of PageSize» or 3584 Bytes 
20 .and. Not(SwapOutFlag)) 

{ 

fail = True — Tell the VM Manager tliat page is incompressible 

Return 

} 



25 



30 



— Store CompSize in Main Map and then Update FreeMapEntry 

Tag = FreeMapEntry 
MainMap(Tag).Size ^ CompSize 

FreeMapEntry = smallest TagValue for which MainMap(TagValue).SizesO 



— Store Incompressible Page In Secondary Memory 

— Check to see if Page at PG should be swapped out to secondary memory 
If ( GrowWS .and. (FreelHeapBytes $ 2 x PageSize) 

35 .and. CompSize > Threshold ) 

{ 

Find SectorPtr to first sector in a sequence of free sectors sufficiently 
large to store page at PG 

40 Store Uncompressed Page from page at PG into Secondary Memory 

starting at sector specified by SectorPtr. 
CompSize » PageSize 

- Store Relevant Bookkeeping Data in MainMap and MapChain 
45 MainMap(Tag).Size s PageSize 

MainMap(Tag).Ptr & -1 - indicates page is in 

MapChain(Tag) = SectorPtr — Secondary Memory Address 
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- Add Page at PG to end of Compression Heap 
Page# = PG / PageSize 

VMPageMap(NextCompHeapPage).Adr = VMPageMap(Page#).Adr 
VMPageMap(NextCompHeapPage).MI s 1 
5 VMPageMap(NextCompHeapPage).MO = 0 

- Leave Modified (MD) flag unchanged 

~ Update FreeHeapBytes and NextComplHeapPage 
FreelHeapBytes = FreeHeapBytes + PageSize 
10 NextCompHeapPage = NextCompHeapPage + 1 

Return 
) 

— Store Page In Corhpresslon Heap 

15 If CompSize ^ Threshold - e.g.. 87.5% of PageSize. or 3584 Bytes 

{ 

If CompSize s -1 - -1 indicates page filled with identical words 

— Special Handling for Page filled with identical words. 

- Word Value is stored in MainMap(Tag).Rr instead of in the 
20 Compression Heap 

{ MainMap(Tag).Ptr s RAM(PG) } 
Else 
{ 

Copy Compressed Page in Compression Buffer into Free Space of 
25 Compression Heap, updating FirstFree and Free Space segment 

linics as necessary 
) 

) 

Else ~ Store Page in Uncompressed Format Mo Compresson Heap 
30 { 

Copy Uncompressed Page from page at PG into Free Space of 
Compression Heap, updating FirstFree and Free Space segment linlcs 
as necessary 
CompSize = PageSize 
35 MainMap(Tag).Size s PageSize 

) 

— Store Relevant Bookkeeping Data in MainMap and MapChain 
MainMap(Tag).Ptr & Pointer to end of the first data segment in which the 

40 compressed page was stored. 

— Add compressed page to Map Chain, unless compression ratio 2 4 
If CompSize > 0.25 x PageSize 

{ 

45 MapChain(Tag).BackPtr s MapChainEnd 

MapChain(Tag).FonA^ardPtr = 0 - Tag s O is invalid value 
MapChain(MapChainEnd).ForwardRr « Tag 
MapChainEnd b Tag 
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} 

~ Add Page PG to end of Compression Heap 
Page# = PG / PageSize 
5 VMPageMap(NextCompHeapPage).Adr = VMPageMap(Page#).Adr 

VMPageMap(NextCompHeapPage).MI = 1 
VMPageMap(NextCompHeapPage).MO » 0 
- Leave Modified (MO) flag unchanged 

10 — Update FreeHeapBytes 

If CompSize = -1 

{ FreeHeapBytes s FreeHeapBytes + PageSize } 
Else 

{ 

15 FreeHeapBytes = FreeHeapBytes + PageSize - CompSize 

If (the Free Space segment into which the end of the Page was copied 
was split into a data segment and a Free Space segment) 
{ FreeHeapBytes s FreeHeapBytes - 6 ) 

} 



20 



Return 
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I 

Table 12 

COMPRESSION MANAGER PROCEDURE 
5 Retrieve and Decompress Page from MappedOut Storage 

ReadCompPagefTag) 

— Locate the Page In Compression Heap or Secondary Memory 
10 HeapLocation s MainMap(Tag).Rr 

CompSize = MainMap(Tag).SIze 
If HeapLocation = -1 

{ SectorPtr = MapChain(tag) } 

15 - Special Handling for Page filled with Identical words. 

If CompSlze= -1 - -1 Indicates page filled with Identical words 
- Word Value is stored in MainMap(Tag).Rr instead of Heap Location 

Word = MainMap(Tag).Ptr 
20 Fill Page at TranslentPageAdr with Word 

Return 
) 

— If page not compressed, copy Page into RAM starting at the Logical 
25 Address corresponding to Page# 

If CompSize s PageSIze 
{ 

If HeapLocation = -1 
{ 

30 Copy Uncompressed Page from Secondary Memory, starting at 

sector specified by SectorRr, into page at TranslentPageAdr 

Else^ - Uncompressed page is in Compression Heap 

35 Copy Uncompressed Page from Compression Heap, starting at 

HeapLocation. into page at TranslentPageAdr 

) 

40 Else 

— tf Page Is compressed, copy compressed Page data Into 
Compression Buffer, then decompress the page and write the 
decompressed data Into RAM starting at the Logical Address 
corresponding to Page# 

45 { 

If HeapLocation s -1 
{ 
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Copy Compressed Page from Secondary Memory, starting at sector 
specified by SectorPtr, into Compression Buffer. 

Else - Page is In Compression Heap 

5 { 

Copy Compressed Page from Compression Heap, starting at 

HeapLocation, Into Compression Buffer. 

— Decompress page in Compression Buffer and store decompressed 
10 page at TransientPageAdr 

Call Decompress(CompSize) 
} 

Return 
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Table 13 

Release Page in MappedOut Storage 

5 Compression Manager releases space allocated to this page 

ReleaseCompPage(Page#) 

- Locate the Page In Compression Heap or Secondary Memory 

Tag = VMPageMap(Page#).Adr 
10 HeapLocation s MainMap(Tag).Rr 

CompSize = MainMap(Tag).Size 
If HeapLocation = -1 

{ SectorRr s MapChain(tag) } 

15 — If page is In Secondary Memory, release the sectors assigned to 

this page 
If HeapLocation s *1 
{ 

Update SectorTable to show as unused those sectors in which Page 
20 was stored. 

MapChain(tag) s 0 *- Clear Disk Address in MapChain 
} 

Eiseif Compsize 9^-1 - If page Is in Compression Heap, add all 

segments for this page to the Free Space 
25 of Compression Heap, updating Free Space 

segment linlcs as necessary 

{ 

Add segments in which page was stored to set of Free Space segments, 
updating Free Space segment links as necessary. If any new Free 
30 Space segment is adjacent a pre-existing Free Space segment^ merge 

the adjacent new and pre-existing Free Space segments. 

- Update FreeHeapBytes 
FreeHeapBytes » FreeHeapBytes -i- CompSize 
35 4* 6 X (Number of segments merged with Free 

Space segments) 
If CompSize > 0.25 x PageSize 

{ Call RemoveFromMapChain(Tag) } 

) 

40 

- Update Bookkeeping Entries in MainMap 
MainMap(Tag).Ptr = 0 
MainMap(Tag).Size s 0 

FreeMapEntry as smallest TagValue (>0) for which 
45 MainMap(T agValue).Size s 0 

Retum 
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Table 14 

Procedure for Removing a Tag from the MapChain 
5 RemoveFromMapChain(Tag) 

- Special Handling if this Is first entry in MapChain 
If (MapChainStart » Tag) 

{ 

10 If (MapChainEnd = Tag) - is this only Item In MapChain? 

{ 

MapChainStart = 0 
MapChainEnd » 0 
) 

15 Else 

{ MapChainStart s MapChatn(Tag).ForwardPtr } 

} 

- Special Handling if this is last entry in MapChain 
20 If (MapChainEnd » Tag) 

{ MapChainEnd s MapChain(Tag).BackPtr } 

- Relink MapChain entries before and after released page, unless page 
was in Secondary Memory 

25 If ( Tag ^ MapChainStart .and. Tag ^ MapChainEnd 

.and. MainMap(Tag).Ptr ^ -1 ) 

{ 

Tempi = MapChain(Tag).BackPtr 
Temp2 = MapChain(Tag).ForwardPtr 
30 MapChain(Temp1).ForwardPtr = Temp2 

MapChalnfT emp2).BackRr s Tempi 
} 

Return 
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Table 15 



Compression Procedure 

5 Compress(Page#,CompSize) 

— Initialize Dictionary Table LastUse 
Base B Page# x PageSize 

Word = RAM(Base) 
LastUse(Word) s -1 
10 Flag4 = True 

For Position s i to PageSize -2 - positions are byte positions 
{ 

PriorWord = Word 
15 Word s RAM(Base -t- Position) 

If Word It PriorWord 
{ Flag4 = False } 
Else 

{ LastUse(Word) = -1 } 

20 ) 

- Special Handling for Page filled with identical words. 
If Flag4 = True 

{ 

25 CompSize = •I 

Return 
) 

- Process first Word (which will be first word in the Dictionary) 
30 Word s RAM(Base) 

LastUse(Word) = 0 
lndexTable(0).lndex = 0 
lndexTable(0).PriorPos s .1 
Nextindex si 
35 Write to CompressBuffer "OVWord 

CompSize s 17 (bits) 

— Process Page in units of 2-Byte words 
Position s 2 

40 Do Until Position 2 PageSize • 2 

{ 

Word s RAM(Base -t- Position) 



— Is this first time Word has been Seen? 
45 If LastUse(Word) « -1 

{ 

— Processing for Word Not Already in the Dictionary 
LastUse(Word) = Position 
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lndexTable(Position^).lndex s Nextlndex 
lndexTabIe(Position/2).PriorPos s -1 
Nextlndex s Nextlndex -f 1 

5 — Special Handling for Audio Data and the like: 

Dif = Word • RAM(Base -t- Position - 4) 
If ( (Position > 2) .and. (|Dif | < 1024) ) 
{ 

Write to CompressBuffer "1 10'+ 
10 Dif (encoded as 11 -bit signed value) 

CompSize » CompSize -t- 14 
) 

Else 
{ 

15 Write to CompressBuffer "OVWord 

CompSize s CompSize + ^7 
) 

Position SB Position + 2 
) 

20 Else 
{ 

— Processing for Word Already In the Dictionary 

PriorPos as LastUse(Word) 
lndexTable(Position/2).PriorPos = PriorPos 
25 lndexTable(Position/2).lndex s indexTabie(PriorPos/2).lndex 

LastUse(Word) = Position 

BestPriorPos = PriorPos 
BestRun = 1 
30 «Tries = 0 

Do Until ( (BestRun » 32) .or. (PriorPoss-1) .or. («Tries«32) ) 
{ 

#Tries = #Tries + 1 

35 RunLength s Number of words In Page, starting at PriorPos. 

which match words starting at the current 
Position, not to exceed 32) 
If RunLength > BestRun 
{ 

40 BestRun » RunLength 

BestPriorPos s PriorPos 
) 

PriorPos = lndexTable(PriorPos/2).PriorPos 
} ~ End of Do Loop 



45 



If BestRun si — Best match s 1 word long: 
{ 

Dindex s lndexTable(Position/2).lndex 
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i 

N s 1 + integerPortion( Log2(Nextlndex) ) 
Boundary = 2'^ - Nextlndex 
If OIndex ^ Boundary 

{ Eindex s (Dlhdex Boundary) encoded as N bits } 
5 Else 

{ 

N = N- 1 

Eindex » DIndex encoded as N bits 
) 

1 0 Write to CompressBuffer '1 0 V Eindex 

CompSize s CompSize 2 N 
Position s Position -i- 2 
) 

Else — Encoding Procedure for best inatch Is > 1 word long: 
15 { . 

Update LastUse and IndexTable entries 

for words at Positlon+2 through Position+(2x(BestRun-1)) 

BeginCase (BestRun) 
20 Case (BestRuns2) 

{ E.Length = 'O" ) 
Case (BestRunsS) 

{ EXength = "10' } 
Case (BestRuns4) 
25 { E.Length = '110" ) 

Case (BestRun > 4) 
{ 

Value s BestRun - 2 

E.Length * '1 1 1 " + Encode(Value,5 bits.unsigned) 
30 } 

EndCase 

DistBack s Position - BestPriorPos 
BeginCase (DistBacIc) 
35 Case (DistBack ^16) 

{ 

E.Distnc = '00' -i- Encode(OistBack -1 , 4 bits, unsigned) 

Case (16 < DistBack ^ 80) 
40 { 

E.Distnc s '01" + Encode(DistBack -17, 6 bits, unsigned) 

Case (80 < DistBack) 
{ 

^5 E.Distnc s 'i" + Encode(DistBack, 1 1 bits, unsigned) 

EndCase 
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Write to CompressBuffer •111"+ E.Length + E.Distnc 
CompSize s CompSize 1 3 (bit length of E.Lenth and E.Distnc) 

Position s Position -i- (BestRun x 2) 
5 } 
) 

} — End of Main Loop 
- Convert CompSize to number of bytes writen to CompressBuffer 
CompSize = RoundUp( Compsize / 8 ) 
10 Return 
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Table 16 
Decompression Procedure 

5 

Decompress(CompSize) - Decompress page in Compression Buffer and store 

decompressed page in the Transient Page at 
TranslentPageAdr 

10 — IndexTable is not used during Decompression 

- LastUse table does not need to be initialized 

- LastUse table is used as a Dictionary during Decompression 

Base s TranslentPageAdr 
15 BitPos = PtiCompBuffer 

Nextlndex s 0 ' 

- Process first Word (whicli will be first word in the Dictionary) 
Word = RAM(Base + 1, 16 bits) 

20 BitPos s BItPos + 17 

LastUse(Word) s 0 



25 



45 



FlAM(Base) = Word ~ Write First Word to Output Page 

LastUse(Nextlndex) s Word - Write Rrst Word to Dictionary 

Position = 2 
Nextlndex s 1 



- Process Page in units of 2-Byte words 
30 Do Until Position ^ PageSize 

{ 

- Processing for Word Not Already in the Dictionary 
If RAM(BitPosition. 1 Bit) s -0" 
35 { 

Word s IRAM(BitPosition+1. 16 bits) 

RAM(Base-i-Position) s Word - Write Word to Output Page 
LastUse(Nextlndex) s Word - Write Word to Dictionary 
40 Nextlndex » Nextlndex -i- 1 

Position = Position + 2 
BitPosition ~ BitPosition -t- 17 
) 



- Special Handling for Audio Data and the like: 
Elself RAM(BitPosition, 3 Bits) s ' 1 1 0' 
{ 



BNSDOCID: <WO_9518897A2_L> 



wo 95/18997 PCT/DS94/14987 

- 77 - 

Dif « RAM(BitPosition 3. 11 bits) 

Dif s Dif with 10th bit replicated In bits 12 through 15 

Word s RAM(Position • 4) Dif 

5 RAM(Base+Position) = Word ~ Write Word to Output Page 

tastUse(Nextlndex) s Word - Write Word to Dictionary 
Nextlndex s Nextlndex 1 

Position s Position 2 
10 BItPosltlon B BitPosition -i- 14 

} 

-> Processing for Single Word Already in the Dictionary 
Elseif RAM(BltPositlon. 2 Bits) « '10' 
15 { 

— Check for very small Dictionary 
If Nextlndex £ 2 

{ Index s RAM(BltPosHion+2, 1 Bit) } 
Else 

20 { 

N B integerPortion( LogjCNextlndex) ) + 1 
Boundary = 2^^ • Nextlndex 
Index = RAM(BitPosition-i-2. N-1 Bits) 
if Index ^ Boundary 

25 { Index = « RAM(BitPosttion-(-2. N Bits) • Boundary } 

Else 

{ N = N - 1 ) 

} 

30 Word s LastUse(lndex) -- Get Word from Dictionary 

RAM(Base4-Position) s Word — Write Word to Output Page 

Position s Position + 2 
BitPosition s BitPosition + 2 -f N 
35 ) 

<- Processing for MultlWord Repeat of Data Earlier in Page 
Elseif RAM(BltPosition. 3 Bits) » '1 1 1 ' 
{ 

40 - Detemnine Run Length (Number of Contiguous Words Repeated) 

if RAM(BltPosltion+3. 1 Bit) « '0" 
{ 

Length 2 

BitPosition » B'ltPosltlon -i- 4 
45 ) 

Elseif RAM(BitPosition-i-3. 2 Bits) ~ '10' 
{ 

Length s 3 
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BitPosition s BitPosition +. 5 
) 

Elself RAM(BitPosition-t-3, 3 Bits) - '110' 
{ 

5 Length = 4 

BitPosition s BitPosition * 6 
) 

Elself RAM(BttPosnion-i-3, 3 Bits) s "111' 
{ 

10 Length » 2 -f RAM(BitPosition-i-3, 5 bits) 

BitPosition = BitPosition + 1 1 
} 

- Detennine Distance Back of First Repeated Word 
15 If RAM(BltPosition, 2 Bits) = "00" 

{ 

DistBack s 1 + RAM(BitPosltion+2. 4 bits) 

BitPosition s BitPosition -f 6 

} 

20 Elself RAM(BitPosition. 2 Bits) » "01 ' 

{ 

DistBack = 17 + RAM(BitPosltion+2, 6 bits) 

BitPosition s BitPosition 8 

) 

25 Elself RAM(BitPosition. 1 Bit) « "1" 

{ 

DistBack ^ RAM(BitPosition+1 , 11 bits) 

B'ltPosltion s BitPosHion -i- 12 

) 

30 

— Copy Repeated Data to New Position 
Source s Base + Position - (2 x DistBack) 
Dest s Base -i- Position 

Copy from RAM(at: Source, through: Source -t- (2 x Length) - 1) 
35 to RAM(at: Dest. through: Dest (2 x Length) - 1) 

Position s Position (Length x 2) 

} - End of Processing for MultiWord Repeat of Earlier Data 
40 } ~ End of Main Loop 

Return 
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WHAT IS CLAIMED IS: 

1 . A virtual memory addressing subsystem for a computer having a central 
processing unit (CPU), and primary and secondary physical memory for storing 
5 pages of memory associated with a defined address space having an associated 
set of virtual memory pages, wherein said defined address space is larger than 
said primary physical memory's storage capacity; s^d virtual memory addressing 
subsystem comprising: 

a page table for storing a status value for each virtual memory page of 
10 said set of virtual memory pages; said page table including a page table entry 
corresponding to each said virtual memory page, each said page table entry 
specifying a tag value corresponding to a location In said primary or secondary 
physical memory; each said page table entry further specifying a plurality of status 
flags for said corresponding virtual memory page, including a Mappedin flag 
15 having a True/False value that indicates when said tag value corresponds to 
a page in said primary physical memory in which said corresponding virtual 
memory page is stored; 

a virtual memory unit (VMU) that translates CPU specified virtual memory 
address values into primary physical address values when said Mappedin flag 
20 in said page table entries corresponding to said CPU specified virtual memory 
address values are True, and that generates fault signals when said Mappedin 
flag in saud page table entries corresponding to said CPU specified virtual memory 
address values are False; and 

a virtual memory manager that responds to each fault signal from said 
25 VM U by updating the page table entry corresponding to the CPU specified virtual 
memory address value which caused said each fault signal so that said page 
table entry specifies one of said prvnary physical memory pages and a Mappedin 
flag having a True value; 

said virtual memory manager Including: 
30 a work space manager that defines a work space and a MappedOut 

storage space for storing said virtual memory pages, said work space comprising 
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a first portion of said primary physical memory pages and said MappedOut 
storage space comprising a second portion of said primary physical memory 
pages and a portion of said secondary physical memory; 

a memory usage monitor that stores memory usage data; 
5 said work space manager including SwapOut selection logic that 

selects, on the basis of said memory usage data, ones of said virtual memory 
pages to be swapped out from said woric space to said MappedOut storage 
space; and 

a MappedOut storage manager that receives from said memory 
1 0 usage manager said virtual memory pages selected to be swapped out. stores 
said received virtual memory pages in said MappedOut storage space, and adds 
the primary physical memory pag(5S in which said received virtual memory pages 
were stored to said MappedOut storage space; 

said MappedOut storage manager including a data compressor 
15 that compresses at least some of said received virtual memory pages prior to 
their storage in said MappedOut storage space, and a data decompressor that 
decompresses said compressed virtual memory pages when said virtual memory 
manager responds to fault signals caused by VMU faults on said compressed 
virtual memory pages; 
20 said work space manager including work space size logic that 

determines, on the basis of said memory usage data, when more pages of said 
primar/ physical memory are needed in said work space and that dynamically 
increases said work space by removing pages of said primary physical memory 
from said MappedOut storage space and adding said pages to said work space. 

25 

2. The virtual memory addressing subsystem of claim 1 , wherein said memory 
usage data stored by said memory usage monitor indicates which of said virtual 
memory pages in said work space were least recently used. 

30 3. The virtual memory addressing subsystem of claim 1 , wherein 
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said memory usage data stored by said memory usage monitor indicates 
which of said virtual memory pages in said work space were least recently used 
and also indicates how many virtual memory pages were accessed by said CPU 
during an epoch whose beginning and end are established by predefined criteria; 
5 and 

said work space logic determines when more pages of said primary 
physical memory are need in said wortc space by comparing how many virtual 
memory pages were accessed by said CPU in one said epoch with how many 
pages are included in said v^ork space. 

10 

4. The virtual memory addressing subsystem of claim 1 , wherein 

said MappedOut storage manager stores each said received virtual 
rnemory page as compressed data when said data compressor compresses said 
each received virtual memory page by at least a predefined threshold 
1 5 compression ratio and otherwise stores said each received virtual memory page 
as uncompressed data. 

5. The virtual memory addressing subsystem of claim 1, wherein: 

said MappedOut storage manager includes logic for preferentially storing 
20 said received virtual memory pages in said second portion of said primary 
physical memory so long as said MappedOut storage page includes a sufficient 
number of pages of said primary physical memory to store said received virtual 
memory pages, and for storing ones of said received virtual memory pages in 
said portion of said secondary memory when said work space size logic in said 
25 work space manager determines that more pages of said primary physical 
memory are needed in said work space. 

6. A virtual memory addressing method for a computer having a central 
processing unit (CPU), primary and secondary physical memory for storing pages 

30 of memory, and a virtual memory unit, the steps of the method comprising: 
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(A) defining an address space having an associated set of virtual memory 
pages, wfierein said defined address space is larger than said primary physical 
memory's storage capacity; 

(B) defining a work space comprising a first portion of said primary physical 
5 memory pages, and allocating each of said primary physical memory pages in 

said work space to a distinct one of said virtual memory pages; wherein some 
of said virtual memory pages do not have a primary physical memory page 
allocated thereto; 

(C) defining a mapped out storage space comprising a second portion 
10 of said primary physical memory pages and a portion of said secondary physical 

memory, wherein said first and second portions of said primary physical memory 
are mutually exclusive; 

(D) storing in said mapped out storage space those of said virtual memory 
pages (mapped out virtual memory pages) In which said CPU has stored data 

15 and which do not have a primary physical page in said work space allocated 
thereto; 

(E) dividing said second portion of said primary physical memory into 
occupied space, in which ones of said mapped out virtual memory pages are 
stored, and free space, in which no mapped out virtual memory pages are stored; 

20 said storing step including (F) compressing at least a subset of said 

mapped out virtual memory pages using a predefined data compression 
procedure to produce a compressed virtual memory page, storing said 
compressed virtual memory pages in said second portion of said primary physical 
memory if said free space has sufficient storage space to store said compressed 

25 virtual memory pages, and otherwise storing said compressed virtual memory 
pages in said portion of said secondary physical memory; and 

(G) responding to CPU specified virtual memory address values 

(G1 ) when said CPU specified virtual memory address values are 
in said pages of said virtual memory to which said ones of said primary physical 

30 memory pages have been allocated, by translating said CPU specified virtual 
memory address values into primary physical address values. 



eNSDOCiD: <WO_9518997Aa_l_> 



wo 95/18997 



PCr/lJS94/14987 



•83- 

(G2) when said CPU specified virtual memory address values 
correspond to said mapped out virtual memory pages, allocating ones of said 
primary physical memory pages in said first or second portions of said primary 
physical memory pages to each of said oon^esponding mapped out virtual memory 
5 pages, storing said corresponding mapped out virtual memory pages in said 
allocated ones of said primary physical memory pages and then translating said 
CPU specified virtual memory address values into primary physical address 
values in said allocated ones of said primary physical memory pages, and 

(G3) when said CPU specified virtual memory address values 

1 0 correspond to virtual memory pages to which no primary physical memory pages 
have been allocated and which do not correspond to said mapped out virtual 
memory pages, allocating ones of said primary physical memory pages in said 
first or second portions of said primary physical memory pages to each of said 
virtual memory pages in which said CPU specified virtual memory values are 

15 located, and then translating said CPU specified virtual memory address values 
into primary physical address values in said allocated ories of said primary 
physical memory pages. 

7. The method of claim 6, 
20 said storing step G2 including, when said CPU specified virtual memory 

address values correspond to ones of said compressed virtual memory pages, 
decompressing said corresponding compressed virtual memory pages while 
performing said storing step in said step G2. 

25 8. The method of claim 6, 

said step D including: storing status information for each of said mapped 
out virtual memory pages, said status information for each of said mapped out 
virtual memory page indicating where in said mapped out storage space said 
mapped out virtual memory page is stored and also indicating whether said 

30 mapped out virtual memory page is stored as one of said compressed virtual 
memory pages; and 
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said step G2 including: inspecting said stored status information to 
deteimine whether said CPU specified virtual memory address values correspond 
to ones of said compressed virtual memory pages, and when said status 
information so indicates, decompressing said corresponding compressed virtual 
5 memory pages while perfonDing said storing step in said step G2. 

9. The method of claim 6, 

said responding step (G) including, in accordance with predefined memory 
usage criteria, removing ones of said primary physical memory pages from said 
1 0 second portion of said primary physical merhory pages and adding those primary 
physical memory pages to said worl< space, 

whereby said first and second portions of said primary physical memory 
pages are variable in size. 

15 10. The method of claim 6, 

further including storing memory usage data indicative of which virtual 
memory pages have been accessed by said CPU; 

said responding step (G) including, in accordance with said stored memory 
usage data and predefined memory usage criteria, removing ones of said primary 
20 physical memoiy pages from said second portion of said primary physical memory 
pages and adding those primary physical memory pages to said wortc space, 
whereby said first and second portions of said primary physical memory 
pages are variable in size. 

25 11. The method of claim 6, 

further including storing memory usage data indicative of which virtual 
memory pages have been accessed by said CPU. wherein said stored memory 
usage data indicates which of said virtual memory pages, to which ones of said 
primary physical memory pages have been allocated, were least recently used; 

30 said re^onding step (G) including, in accordance vyoth said stored memory 

usage data and predefined memory usage criteria, removing ones of said primary 
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physical memory pages from said second portion of said primary physical memory 
pages and adding those primary physical memory pages to said work space, 
whereby said first and second portions of said primary physical memory 
pages are variable in size. 

5 

12. The method of claim 11, 

wherein said stored memory usage data also indicates how many virtual 
memory pages were accessed by said CPU during an epoch whose beginning 
and end are established by predefined criteria; and 
10 said responding step includes detenmining when more pages of said 

primary physical memory are need in said work space by comparing how many 
virtual memory pages were accessed by said CPU in one said epoch with how 
many pages are included in said work space. 

15 13. The method of claim 12, further including 

storing data denoting which of at least a predefined subset of said mapped 
out virtual memory pages were stored first in said second portion of said primary 
physical memory pages, and 

said removing step including moving said first stored mapped out virtual 
20 memory pages from said second portion of said primary physical memory pages 
to said portion of said secondary physical memory. 

14. The method of claim 6, 

further including, responding to a deallocation of a CPU specified virtual 
25 memory address range by a program being executed by said CPU by filling said 
CPU specified virtual memory address range with predefined highly compressible 
data. 
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